Update of drupal 8 version

Hi,

However, most effort should be put into https://www.drupal.org/node/1234624, for now I have created a small module that will allow delta for images.

https://github.com/haringsrob/Drupal-image-delta

@Raphael - Thanks for the patch!

I haven't committed your patch wholesale, as it contains some unnecessary whitespace changes. Instead I'm making several commits as I update the whole module, and I'll give you authorship credit for anything which was also mentioned in your patch. You should see several commit credits on your user profile already.

As mentioned in #1234624-90: Limit the number of fields to display, I created a sandbox Field Limiter module for D8. If you like the approach, I'd be happy to merge the code with this project.

Hello,

Today I had been granted ownership on the https://www.drupal.org/project/field_formatter_range module because it was unsupported since at least two years.

The module listed this one as a D7 alternative.

I saw the Field Limiter module in the comment above and listed both modules on Field Formatter Range project page.

Although Field Limiter as a different architecture. I don't know if it will be possible to avoid effort duplication or if both approaches has to keep living.

Regards,

@grimreaper I completely agree that we should avoid duplication whenever possible. Suppose there are no practical limitations, what would you propose? Which technical approach would be used, under which module name would it be published, who would be the maintainer?

Hello,

@marcvangend thanks for your reply.

Here is the approach I would take:

1. List all the features of each three modules
2. List the pros and cons of each module technical solution
3. If one of the technical solution allows to have the behavior of the other modules preserved, agree to recommend this module and put the others into "maintenance only" status.
4. If the agreement is reached, put at least one maintainer of the other modules as maintainer/co-maintainer (I don't have the exact diff between the two terms if there is one) of the module that will be agreed on.
5. If there is no clear technical solution that fills all the needs, each module has to be kept and linked to each other so users can choose the more adapted to their need.
6. If there is a technical solution that will fill all the needs, and is not currently implemented in any of three modules, let's create a new module with this architecture and make step 3 and 4 with this module elected.

The three modules I talked above are:
- Field Multiple Limit
- Field Limiter
- Field Formatter Range

Are you ok with this approach?

#11 sounds like a good plan to go forward. Thank you! As the maintainer of field_limiter I will be happy to cooperate.

Thanks for your reply.

I hope we are not hijacking too much this issue...

1: List all the features of each three modules

Field Formatter Range

- Alter every field formatter to add options
- Combination of limit and offset to be able to select precisely which delta to display of the field.
- Allow to reverse the order
- #2988031: Add support for random ordering
- Layout builder integration

Field Limiter

- Combination of limit and offset to be able to select precisely which delta to display of the field.

Field Multiple Limit

- Combination of limit, offset, number of value to display to be able to select precisely which delta to display of the field.

2: List the pros and cons of each module technical solution

Field Formatter Range

Pros:
- Add options on existing field formatters
- Layout Builder support
- Additional features (reverse, random (in patch))

Cons:
- Do not support Views: but if you render a multivalued field with Views there are already options for, range, offset and reverse. But a "randomize" feature will not be supported in views.

Field Limiter

Pros:
- Build on top of Field Formatter module, so that allows to use other existing field formatters
- Usage of OOP code, so the plugin is extendable/overridable
- Views support

Cons:
- Do not support Layout Builder (due to Field Formatter), #3047981-9: Compatibility with layout builder?
- On dev environment with XDebug, due to Field Formatter, got error "Maximum function nesting level of 500 reached, aborting!"

Field Multiple Limit

Cons:
- Module not functional

3: Results

Field Multiple Limit has the highest number of website using it due to D7, but there is no functional D8 version. Also on the 8.x-1.x branch, the architecture will give almost the same thing as Field Formatter Range, I think.

In my opinion the choice is between Field Formatter Range and Field Limiter.

Field Formatter Range has a minimum of 353 usages.
Field Limiter has a minimum of 208 usages.

I don't think this difference is important enough to help make a decision.

I think Field Limiter has a better architecture due to be built on top of Field Formatter. But even if some features like "reverse" or "random" could be added to the module, I am very worried of all the side effects of Field Formatter, see #3047981: Compatibility with layout builder?.

Also I didn't dive in Field Formatter, but I hope its architecture do not have performance issue due to a field formatter "pluginception".

#3050938: Field limiter does not always output the requested number of items I think Field Formatter Range has the same problem.

I tried to be the most objective as possible. If I missed a feature or some architectural pros/cons, please add it.

In my opinion, it is not clear enough we have one module better than the other.

Hi all,

Much belatedly, I am marking this module as minimally maintained as it's clear I and the other co-maintainers have not been active on this for several years.

Instead of including the broken D8 version of this module, I updated the project page to point people to Field Limiter, Field Formatter Range, and the comparison above.

I'm marking this as needs review in case anyone wants to provide feedback; if there is none then I will close this issue as resolved.

Hi all,

Thanks @rootwork