New links module?

Add ons
21

Looks epic! What do you need to get this across the line for release / with elemental? Looking to fix this for an upcoming project and seems like this module is the nearest we have to a next step forward.

22

It’s pretty high up on our road map. We still have some outstanding architectural decision to make.

Mainly:

  • Should this be a separate unsupported module, a supported module or should it be part of a core module.
  • How do we want to store the link data? Right now you can store it as plain JSON and as a DataObject. It’s unlikely we’ll want to support both those options.
23

Sweet!

My feedback on those 2 points:

  1. Either seperate module which doesn’t have any dependancies or if we’re going to use it within the admin UI then it could be part of the admin module (which elemental requires anyway) Debatable whether a link field would be useful in a framework only context.

  2. I would vote towards a DBComposite field ala Money field type that way versioning works seamlessy.

24

Hello everybody!

The CMS Squad is investing some time into this project and we would like to gather some more feedback from the community.

This is needed so much. It’s a constant source of pain for me.

It’s a constant source of pain for me too.

Any update on this becoming a thing?

We went with “Data Model Option B” and I regret that now

@Tim @Greg_808 @wilr @AirNZ-Mike

What are the main problems with gorriecoe/silverstripe-linkfield or what use cases it does not cover for you? (apart from not being security audited)

25

Biggest issues with that module for me is the UI of it, doesn’t work well within Elemental inline editing and basically using GridField is a bit of a shortcut for the dev rather than user friendly (i.e if we have 3 block links each with its own has_one field picker it clutters the UI up). Would rather have something supported across elemental (like the one bundled in banner block) but extensible.

Taking a look at what you’re started with under silverstripe-linkfield so far I’d like to repeat @chillu’s concerns with subclasses for each link type, before a 1.0 it would be create to see how many additional queries this creates.

Take the example above you have 3 link fields per block on the home page, say 4 blocks on the page (12 links all up) if you did it as a DBComposite you would have that information without any additional queries.

As doing it via subclasses are you not going to see 12 additional queries at least (with the required joins). Be interesting to know the impact, I imagine you could try a common thing such as a list of branches, each branch has a link to their website and an email link. ~50 branches x 2 links = 100+ additional queries?

1 Like
26

Hi everybody!

Here’s an update regarding our progress.

We have prepared the RFC-30: Data Model describing how we would persist links in the database.
The RFC-30 is now finalized and a PoC (proof of concept) has been implemented.
It is now ready for a general discussion. If you’re interested, you’re welcome to have a look at it and join in the discussion.