search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

[D8][META] Consider adding modules/features to core for parity with Drupal 8/9/10 #378

Open dgoutam opened 10 years ago

dgoutam commented 10 years ago

Based on the presentation by Dave Reid at Drupalcon Amsterdam 2014, the "Core modules" list in d.org and other sources (like the d.org issue queue and the D8 change records).

Modules to be added:

Other misc changes we might also want to consider:

**Feature parity with the Layout Builder module in modern drupal:

Modules/features already added:

Not planned/needed in Backdrop:

Removed from d8 core:

dgoutam commented 10 years ago

@quicksketch @jenlampton is there any policy document how to include this modules to backdrop for contributors? It will be super helpful if this kinda document exist for the contributors. For me kinda confused how to include these modules (let say joyride) into backdrop.

Could it be simple PR? If so I can take few.

quicksketch commented 10 years ago

Could it be simple PR? If so I can take few.

We have a docs page at https://backdropcms.org/develop/pull-requests on an intro to contribution.

That said, I don't think many of the modules not already included are likely for a 1.0 release. We're planning on releasing in less than 2 months, so adding yet more modules that we haven't even yet begun is a risky endeavor that could push back our release. We could start working on some of these for a later release (e.g. start work on the CKEditor port), but actual inclusion would likely need to wait until after 1.0.

Areas in which we need the most help right now are in Views conversions (https://github.com/backdrop/backdrop-issues/issues/151) and CMI conversions (https://github.com/backdrop/backdrop-issues/issues/169). There are also a number of bugs that we've noticed that are reasonably easy to tackle, and a few security issues (https://github.com/backdrop/backdrop-issues/issues/180). Finally, we've just initially finished Layouts (#86), and we have a number of followups from that in #345.

attiks commented 9 years ago

FYI picture 2.x now works without breakpoints module, if there's interest we can start porting the relevant parts.

quicksketch commented 9 years ago

I think the only relevant portion of the HTML5/picture business that is relevant to Backdrop is the use of srcset (http://css-tricks.com/responsive-images-youre-just-changing-resolutions-use-srcset/), which I'd love to see built directly into Image module. I haven't tried out the Picture module recently to know how extensive it's solution is, but I think if we can focus on solving the problem of matching up an appropriate image to the device resolution, we'll be in good shape.

If it's not over-simplification, I'd love to see this boiled down to just a single (by default enabled) option either the image formatter or on the image style:

[ ] Generate images for high-resolution and mobile displays

That would automatically generate 50% and 200% versions of the given image and update the srcset to use them. Advanced granularity beyond that may be best left to contrib. Thoughts?

klonos commented 9 years ago

That would automatically generate 50% and 200% versions of the given image and update the srcset to use them. Advanced granularity beyond that may be best left to contrib.

Sounds good to me.

attiks commented 9 years ago

@quicksketch srcset will cover most use cases, but the problem is that - for the moment - you'll need to output a picture tag and use the polyfill, if you only use srcset you ran into problems:

Generating 50%, 200% versions of the same image is not going to help a lot, assuming you'll only want dpi switching it means it will generate a 0.5x and a 2x version. The 0.5x version will not be used since all devices are art least 1x, the 2x version is not sufficient, since most modern phone are 1.5x, 2x, 3x and I even believe there's a 4x phone.

So the above means that it might be better to add support for srcset and sizes, for the moment in Drupal 7 this boils down to selecting some image styles on the formatter and entering a sizes string. The difficult part is entering the sizes string because it is brand new for most people and a bit difficult to comprehend.

Best explanation can be found at http://ericportis.com/posts/2014/srcset-sizes/

I agree that adding full picture support with media queries, mime type support and sources can be left for contrib.

quicksketch commented 9 years ago

you'll need to output a picture tag and use the polyfill, if you only use srcset you ran into problems:

  • browser without srcset support will prefetch the image specified in src, resulting in a double download
  • safari only supports 1x 2x qualifiers so you cannot use sizes, which is the most used form

Could we try to plan ahead by essentially leaving <img> output identical to what it is now, but adding in srcset using either the w or x syntax (I'm not sure which would be better)? If we leave polyfill support to contrib, it could override the srcset attributes to set them in a way where double-loading would be prevented. Without a polyfill, the browser would just treat images as they do currently, reading out the normal src attribute.

The 0.5x version will not be used since all devices are art least 1x

You're right it's too early to build in a 0.5x version considering browser support. Once browsers get smarter, a 0.5x version may become a best-practice for supporting mobile or other situations where users are network constrained. A browser knows if it's on a slow connection, and could use the low-resolution image when possible. However, that's just theoretical for now.

The difficult part is entering the sizes string because it is brand new for most people and a bit difficult to comprehend.

After reading that article you referenced, I don't think sizes is something that can be easily understood by site builders. It appears users would need to know the breakpoints of their layout and where the images will be used within that layout. That makes sizes a poor fit conceptually for image styles, which can be used anywhere throughout a site in any number of places. Coupled with different layouts being allowed different breakpoints, asking an end-user to supply sizes is going to be difficult even when they understand how it's supposed to be used.

jenlampton commented 9 years ago

Great conversation going on over here, thanks @attiks for your insight on responsive images! :)

attiks commented 9 years ago

@quicksketch

srcset: w or x syntax?

The w syntax is the preferred way, but it means you'll need to add sizes as well. The easiest to implement is the x syntax and it can be easily done without a polyfill. This can be done without an interface, but we need to pick the right multipliers, I guess to be safe we need: 1x, 1.5x, 2x, 2.5x, 3x

The problem might be that images need to be upscaled, which is something that should be avoided, so we need an easy way to detect this or allow a site builder to disable certain multipliers?

Contrib can add support for sizes using a different image formatter.

klonos commented 9 years ago

...or instead of upscaling, prompt the user to insert the larger image (use it for the larger multiplier) and downscale it for the smaller multipliers. Does that make any sense?

attiks commented 9 years ago

@klonos it sure does make sense, but does this mean we're going to add a validation to make sure the image is at least 2000px wide, or is it just about adding a description to ask the user to insert a big enough image. In the latter case we need to make sure the derivative can be created without upscaling.

klonos commented 9 years ago

Just asking users to insert their largest variant I guess. After some time (either through trial and error or through our documentation), people will be trained to do so anyways.

Checking for minimum size simply does not make sense to me. What would that size be? Would it be acceptable for all use cases?

klonos commented 8 years ago

...added https://www.drupal.org/project/entity

mikemccaffrey commented 8 years ago

@klonos Shouldn't we not need the entity project, since @quicksketch integrated the Entity API functionality into core in #49?

klonos commented 8 years ago

I couldn't possibly answer that question. It's my understanding that with #49 only a subset of the module was merged into core. I don't know what was left out or why or whether there's more to be done in order to be in par with D8. I believe that @quicksketch is the right person to answer that.

I simply added the module to the list because I saw the "This module has been included with Drupal 8 core." section on the project page in d.org. I then checked our list here and saw no mention of it. So I added it. If it is deemed that we need not do anything else, then I'll just close #1371 as a duplicate of #49 and I'll update the list in the issue summary accordingly.

klonos commented 8 years ago

Updated the list from the Drupal Contrib Tracker and filed respective issues (or linked to already existing ones).

mikemccaffrey commented 8 years ago

Hey @klonos, thanks for creating all of those tickets for modules that have been moved into Drupal 8 core! We definitely should go through them and see what we can move into backdrop core.

However, the whole concept of Drupal 8 parity is perhaps something that we should not be heavily pursuing, since we are actually trying to differentiate ourselves from the drupal community, and one of our core tenets is that we are trying to keep things simple by only including features in core that will be used by a majority of sites.

Having looked at all of these modules, do you have recommendations about which are the most important to move into core, and which modules we might want to mark off as being kept in contrib?

docwilmot commented 8 years ago

the whole concept of Drupal 8 parity is perhaps something that we should not be heavily pursuing

:+1:

I maintain the aim should be "user experience parity" with Wordpress. :smile:

docwilmot commented 8 years ago

P.s. I like "Save Draft", and "Menu Block". All the rest, not so much for core.

klonos commented 8 years ago

Yeah, I hear you both. I believe that this issue here was never meant as a todo list rather than a list of things to consider. The parity thing is in order for D7 undecided people to not have many excuses to not move to backdrop. We should aim to be a Drupal 8 alternative - not a copy with different code base. Perhaps the title change communicates the intention a bit better.

Talking about Wordpress...

klonos commented 8 years ago

I haven't been visiting d.com for a while and they seem to have launched their new site design (based on D8 I guess). Has anyone noticed that they use Backdrop for their "Who Uses Drupal?" site showcase though? Amazing!

drupal com_uses_backdrop

klonos commented 8 years ago

There's a list of modules that are planed for inclusion in D8.1 and are currently in experimental status but shipped with core nevertheless. I made a separate list in the issue summary and I'll file separate issues for each one shortly.

klonos commented 8 years ago

...not sure about the whole family of migrate* modules. We have https://www.drupal.org/project/migrate and https://www.drupal.org/project/migrate_d2d listed in the "not planned/needed" section, but I don't recall any issue or discussion about this.

jenlampton commented 8 years ago

...not sure about the whole family of migrate* modules. We have [some] listed in the "not planned/needed" section, but I don't recall any issue or discussion about this.

We don't need migrate in core because we already have a supported upgrade path in core via update.php. Our target audience are sites that are less likely to use migrate and more likely to use update.php. Whereas the enterprise are more likely to throw out an existing site and start over, migrating in their previous content. Migrate should exist for Backdrop but in contrib.

olafgrabienski commented 6 years ago

Added two Views related features: #2921 and #2922.

klonos commented 6 years ago

I have updated the issue summary, and have added #2498

klonos commented 1 year ago

I believe that given that we have the Feature parity with Drupal GitHub project to help us track issues + also the various [Dx] keywords that we are using in the titles of the issues, perhaps we should close this issue here.

I'll leave it open for a while longer, but will close it next time I am brought here unless there are objections to that.