Follow-up to #2830581: Fix ContentModeration workflow type to calculate correct dependencies

Problem/Motivation

Content Moderation can be applied to entities that are revisionable but not those that are not. See #2850627: Do not require a revisionable entity type when using content_moderation.. It does not check if the the entity is use EntityPublishedInterface. The states offer settings around setting the default revision or published state.

This issue will decide what is the correct set of conditions that means you can apply content moderation to a specific entity type.

See also:
#2825973: Introduce a EditorialContentEntityBase class for revisionable and publishable entity types
#2812811: Use EntityPublishedInterface during moderation of entities to add support beyond nodes
#2850353: Test content_moderation with a non-bundleable content entity
#2842692: Warn users before enabling moderation on an entity type that can't be (un)published

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Our current logic for building CSS and Javascript aggregates suffers from a number of issues:

1. When files don't exist on the file system, they're generated inline, this means that the HTML for any page containing the same aggregate can't complete until one of the pages requested has built it.
2. Additionally it requires state gets and sets to keep track of file names. This was more of an issue in Drupal 7 with variables, but still not ideal.
3. Generating aggregates, especially for CSS, can be quite expensive, so this adds significantly to the time taken from a cache clear to 'first full page request served'.
4. Because it's expensive already, it makes it difficult to add on-the-fly js minification and similar, since that would further degrade cold cache performance.

Proposed resolution

Instead of generating files inline, generate a filename with enough information for the following:

1. The group the filename represents
2. A hash of the css/js asset definitions from the libraries to ensure the code base matches and that updated library definitions result in new aggregate filenames.

These are enough to guarantee unique hashes for the files themselves.

Then add the following in the query string so that the PHP request has sufficient context to generate that same hash:

1. The libraries for the request that were used to generate the groups
2. The theme for the request.
3. For javascript, whether the asset is rendered in the header or the footer (we divide js in two, then build groups for each).

Remaining tasks

Reviews.

User interface changes

None.

API changes

Quite big changes to the optimizer/grouper class logic and potentially an extra interface needed.

Data model changes

Will drop two state entries.

Install new module page /admin/modules/install reads:

For example: http://ftp.drupal.org/files/projects/name.tar.gz

Drupal.org hasn't used that protocol for some time. The text would better read:

For example: https://ftp.drupal.org/files/projects/name.tar.gz

In Drupal 7, thanks to the implementation of l(), an "active" class was automatically added when generating node listing with views, and when the linked entity's URI was the same as the one listed.

With #1979468: ".active" from linkGenerator(), l() and theme_links() forces an upper limit of per-page caching for all content containing links, this is not the case anymore and it seem's not easily alterable (I can't my way through).

Is there a way to change this behaviour. Are we missing something in core to let us alter that ?

It's common for sites in version control to include a "settings.inc" file in sites/default that is used to version control site configuration, while keeping sensitive information (keys, passwords, etc) in settings.php. When system_requirements() runs, it will automatically change the permissions of the site directory to remove write permissions. Then, when running git pull, the merge will break because write permissions are missing on the directory.

Here's a patch that adds a "drupal_install_fix_file_disable" variable that can be used to disable chmod'ing files. system_requirements() still throws an error, but I think that's desirable. I'd be open to downgrading the requirement to a warning if this variable is set.

If this approach is sound, we'd still need to add an example to settings.php so it's known that the variable exists.

Problem/Motivation

When you create a file field, you can enable the description field for each file. This field description is supposed to override the file name on display.
It is working properly with the "Generic file" formatter but not with the "Table of files" formatter.

More than just fixing this bug (it was working in 7.x) we decided to add a setting on the concerned formatters to let the site builder choose if she wants the file name to be overriden by the description.

Proposed resolution

- pass the file description to the theme so it can be used instead of the file name
- add a setting to the "Generic file" formatter to use the description when available
- add a setting to the "Table of files" formatter to use the description when available
- add an upgrade path to disable the new settings for existing "Table of files" formatters (Backward Compatibility)
- increase test coverage to ensure these new settings are working

Remaining tasks

User interface changes

A new setting allows the site builder to define if she want the file name to be overriden by the description when it's available.
The file description is shown, when available and when the formatter allows it, instead of the file name when using the "Table of files" or "Generic files" formatter.

API changes

None.

Data model changes

A new setting on the file_table and file_default formatters.

We upgraded our site from Drupal 6.34 to 7.34 and ran into the PDOException Issue (1003788). We have been using a patch derived from patch #204 since 7.34 and it works like a charm. However, since 7.37 supposedly committed this patch, after updating to 7.37 we got the following warning.

Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 175 of /home/www/drupal-7.37/includes/entity.inc)

Cron will not run, and all page-loads (logged in or not) have this warning. We didn't have this warning when using the 7.36+1003788#204 patch solution.

Looks like this is an old bug somehow resurfaced, but I'm not sure how to fix it.

https://www.drupal.org/node/2476821
https://www.drupal.org/node/1102570

Attached is the derived patch file by our developer.

Problem/Motivation

Block titles can currently be displayed or hidden by site-builders. When hidden, the heading element is omitted from the HTML entirely. Hiding titles might be desirable for a visual design, however block titles can be useful for visually impaired users, providing contextual clarity and navigational cues via screenreaders.

Proposed resolution

Add another option in block configuration, to output visually-hidden block titles, with a "visually-hidden" class.
In D7 this functionality is provided by the a11y_titles module.

We have already added equivalent functionality to D8 for the FieldAPI label display. Offering visually-hidden block titles will extend the options available for site builders to fine-tune the page structure.

Before

After

Remaining tasks

• Usability review: this accomodates an additional option by replacing a checkbox with a select element, similar to the label display for field formatters.
• Documentation: explain the visually-hidden option on the block help page?
• Update settings form in \Drupal\Core\Block\BlockBase::buildConfigurationForm()
• Update HTML output in block module, adding "visually-hidden" class to title_attribute twig variable via template_preprocess_block. The block twig template does not need to be changed.
• Update block settings config schema. Not necessary - block_settings.label_display is already type: string, not boolean.
• Update installation config in core profiles/modules, changing block_settings.label_display values of '0' to explicit 'hidden'. It would be a BC break so keep the '0' value for hidden titles.
• hook_update(). Change block_settings.label_display values of '0' to explicit 'hidden'. Not usefull anymore (see previous)
• Write tests.
• Some blocks have custom behaviour, e.g. menu blocks already have visually hidden titles, and Bartik uses it's own CSS to hide block titles in the header region. Come up with an approach for these - we might be able to remove custom templates and CSS, relying instead on installation config. Should be done in follow-up issues.

User interface changes

Block title display option changes from a boolean checkbox option to 3 options in a select element: Visible, Visually Hidden, Hidden.
Aim for consistency with the Field API options in entity manage-display settings.

Also descriptive help text may change (D7 a11y_titles module says "Block titles can provide context to users who can’t rely on visual cues").

API changes

None expected.

Data model changes

We are introducing a third option to Block title display: 'visually-hidden'. Effect on data model are as follows:

• Config Schema: NO CHANGE. While we are introducing an additional option ('visually-hidden') for the core data type block_settings.label_display, this is already of type: string, which accommodates all proposed values (visible, visually-hidden, hidden).
• Installation Config: CHANGED. Block configuration files in config/install folders will need to be updated, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC
• Existing Sites' Config: UPDATE HOOK required, changing block_settings.label_display values of '0' to explicit 'hidden'. Removed for BC

Problem/Motivation

I am working on a site which requires quite a specific and detailed element/attribute whitelist. My "allowed_html" setting is 1200 characters long. When updating this, it's impossible to tell from a diff what changed. In addition to this, we've found that changes manually made to the attributes and classes are reverted, chopped and changed by Drupal.behaviors.filterFilterHtmlUpdating erroneously, possibly from a bug in the JS or one of the filters we have installed.

It would be great if the schema that stored these settings provided a better diff.

Proposed resolution

Update the schema to look something like:

    allowed_html:
      type: sequence
      label: 'Allowed HTML'
      sequence:
        type: sequence
        label: 'Attributes'
        sequence:
          type: string
          label: 'Value'

Which would transform settings like:

allowed_html: '<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type>'

Into:

      allowed_html:
        a:
          href: '*'
          hreflang: '*'
        em: {  }
        strong: {  }
        cite: {  }
        blockquote:
          cite: '*'
        code: {  }
        ul:
          type: '*'
        ol:
          start: '*'
          type: '*'

Remaining tasks

Validate & see if this is something we can achieve without breaking BC.

User interface changes

API changes

Data model changes

Problem/Motivation

Follow up to #2844594: Default workflow states and transitions.

Currently we have a workflow config entity type and WorkflowType plugin. The schema of the workflow entity is such that each plugin may define the schema of the settings stored for each entity:

workflows.workflow.*:
  type: config_entity
  label: 'Workflow'
  mapping:
    ...
    settings:
      type: workflow_settings.[%parent.type]
      label: 'Settings for workflow type'

These settings hold the states and transitions the workflow will have, as well as any other bits of config the specific workflow type will need to store.

Right now, there are several setters and getters on the workflow entity which assume the structure in the settings. This is incorrect because this structure isn't enforced anywhere and shouldn't be relied on.

Proposed resolution

Instead of the workflow entity changing the workflow settings, all methods required to set/get workflow concepts like states and transitions and additional associated settings should be encapsulated in WorkflowTypeInterface. That way the schema of the states and transitions is internal to the plugin and exposed only via an interface. The end goal being $this->settings is never used in the workflow entity.

Remaining tasks

• Track progress of #2844594: Default workflow states and transitions.
• Write a patch.

User interface changes

None.

API changes

API changes to the way states and transitions are created and accessed.

Data model changes

Minimal data model changes, as the schema change has been done in #2844594: Default workflow states and transitions.

Problem/Motivation

When saving a new revision of an entity to have a moderation state that affects the default state it is possible to inadvertently change other translations of the entity to become the default revision. An update made prior to Content Moderation being committed prevented translations inadvertently becoming unpublished due to this issue, but in turn caused draft revisions to become "missing", although they exist in the database they cannot be accessed via the UI to create a new revision from.

Steps to reproduce

1. Enable Content Translation and Content Moderation modules
2. Add french language on languages page (i.e. /admin/config/regional/language)
3. Enable translation for article node type on content translation page (i.e. /admin/config/regional/content-language)
4. Enable "editorial workflow" for article node type on workflow's edit page(i.e. /admin/config/workflow/workflows/manage/editorial)
5. Create an article in english and publish ('Save and Publish' button)
6. Translate to french and publish ('Save and Publish' button)
7. Go to french version of the article. Make changes and save as draft ('save and Create New Draft (this translation)' button)
8. Go to english version of the article, you won't be able to add a new revision.

Actual:
Article reverted back to last published version and no draft version available in revision tab (ref: screenshot).

Proposed resolution

Prevent users from changing the moderation state to something that would cause cause a draft revision to become "missing".

Remaining tasks

- Review.
- Improve help text.
- Follow up to rework translations / revisions storage to allow complex workflows.

User interface changes

- Removal of save buttons which will cause issues.
- Additional help / error text.

API changes

none

Data model changes

none

A simple case is to output the number of nodes created per month. We can use Count to aggregate the number but there seems to be no option to enable per-month aggregation for 'created' timestamp - only 'Value' aggregation is available.
MYSQL has 'FROM_UNIXTIME()' feature for this case (not sure about other DB engines).

Problem

With all the shiny new frontend stuff we're exposing users to, there are more animated elements on pages. Those animations can cause motion sickness reactions on some people. See child issues.

For those curious here is an article from the guardian about ios issues and some more details from wikipedia's motion sickness page.

a11y is a core gate, we have to find a suitable solution that allows us to remove/reduce all animations in core and contrib. I'll paste text from a reply of Charles Belov in the tour animation issue:

In my mind it would be part of core, just as the iPhone offers a "Minimize animation" setting in its native settings. The idea is that Drupal 8 will be accessible out of the box.

The other advantage of putting it in core - aside from Tour being accessible out of the box - would be that it would encourage contibs that utilize animation to query that setting and respect it. If Minimize Animation was in and of itself a contrib, that would greatly reduce the likelihood of other contribs querying it.

Proposed solution

The plan is to add a sitewide and user-level setting to toggle animations. This setting will do:

1. jQuery.fx.off = true;
2. Add no-animate.css file containing: .no-animate * {transition:none !important}
3. There will be a new setting available for core and contrib JS: drupalSettings.noAnimate. That way code can do if (drupalSettings.noAnimate) {} directly and we don't have to add this when animations are on (which is by default).

Problem/Motivation

The tracker module currently depends on the comment module even if some of it's functions are not related to comments at all (eg. see if a node has been created/updated since our last visit). Sites that does not have comments or that's using another comment module than the core's one (eg. Disqus) cannot use the abilities of Tracker on nodes.

Proposed resolution

Remove comment module dependency and use a condition wherever it's needed to keep existing functionnalities active if the comment module is installed.

Remaining tasks

User interface changes

Comment module is no longer required to enable tracker module.

API changes

None.

Problem/Motivation

While using the Book navigation block in "book page" mode, it would be nice to be able to override the block title by the book title.

Proposed resolution

Add a block setting to override block title by the book title.

Screenshots

	Before	After
Back
Front

Remaining tasks

User interface changes

A new setting is available on Book navigation block settings form.

API changes

None.

Data model changes

A new setting on block.settings.book_navigation

Follow-up to #2863268: Convert web tests to browser tests for tracker module

See #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase)

Problem/Motivation

The overall goal is to make more site edit/build functionality available directly on the frontend of your site (“turning Drupal outside in”). A current example of this is the "Edit" button (toggle) top right in the toolbar:

This button in itself has usability issues but new developments like #2724819: Create experimental module for place block on any page feature are adding their own seperate links to the toolbar. Which obviously does not scale well:

We need to find a way to scale this pattern so that besides content editing we can also expose interactions for "add new", "rearrange" and others. The general idea could be to have a global View/Edit/Build toggle for example which could show a sidebar with applicable tools.

Proposed resolution

Image links to attached video

Trigger an "edit mode" in which links are disabled but all blocks are tap/clickable. Taps/clicks trigger an off-canvas configuration tray which separates content and configuration tasks into two tabs (the above prototype shows the toggle and off-canvas tray integrated with the experimental "place block" module).

Remaining tasks

- List potential interactions to expose
- Rank them: what are the 80% use cases, which are more on the side of 20%?
- Define an initial scope
- What are existing contrib solutions in this space?
- Explore designs options
- Prototype, test, iterate
- Decide on the preferred design
- Write up a spec
- Write the patch (in a followup issue?)

User interface changes

See child issues.

Upgrading a very small site from 6.2 to 7.0, just looking for advice. When attempting to run update it starts and then dies here:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://www.fourtiresandfuel.com/update.php?id=18&op=do StatusText: Service unavailable (with message) ResponseText: Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /home/hoslot5/public_html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1262 of /home/hoslot5/public_html/includes/database/select.inc).

Error page:
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).
Notice: is_dir() [function.is-dir]: Unable to find the wrapper "public" - did you forget to enable it when you configured PHP? in file_scan_directory() (line 1975 of /home/hoslot5/public_html/includes/file.inc).

The update process was aborted prematurely while running update #7012 in user.module. All errors have been logged.

If this is posted somewhere and I missed it I apologize, I need sleep :)

Problem/Motivation

The current workflow UI is very disjointed. Each link to Create, Update, or Delete a workflow state or transition takes the user off to a new page, which can result them getting lost, or at best a few clicks away from where they started.

Proposed resolution

As proposed in https://marvelapp.com/1124911 the new workflows UI is a unified single area for Creating, Updating, and Deleing workflow states and transitions.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Busy sites that use a lot of forms can make a lot of entries in the cache_form table. This is particuarly true of sites using Ubercart, Commerce, or other modules like Fivestar, Ideal Comments, or Hierarchical Select.

This is a very common problem which I have seen cause problems for my clients, especially when database replication is involved. A search shows how widespread the issue is: https://www.google.com/search?q=cache_form%20big

The cache_form table is truncated via cron, in system_cron. The default expiry for cache_form entries is 6 hours, hardcoded in form_set_cache.

Proposed resolution

By changing $expiry = 21600; from a hardcoded variable to variable_get('cache_form_expiry', 21600);, users can choose how often entries are pruned from cache. With shorter lifetimes, the form_cache table will be truncated more often, and will not grow as large.

I would suggest making the default expiry one hour, rather than 6, also.

Remaining tasks

None, subject to community review (especially of the comment).

User interface changes

None.

API changes

None.

Related Issues

#226728: Temporary cache table entries are not flushed
#1694574: drupal_process_form() deletes cached form + form_state despite still needed for later POSTs with enabled page caching

Related Modules

Safe cache_form clear