Quantcast
Viewing all 296290 articles
Browse latest View live

Impossible to update drupal/core to 8.7.0 with Composer if drupal/jsonapi:1.24 is installed, although the 8.7.0 release notes indicate that it should work

composer update installs drupal/core:8.7.0-alpha2 if you have jsonapi:1.24.

A try to composer require drupal/core:8.7.0 result in:

  Problem 1
    - don't install drupal/core 8.7.0|remove drupal/jsonapi 1.24.0
    - don't install drupal/jsonapi 1.24.0|don't install drupal/core 8.7.0
    - don't install drupal/core 8.7.0|don't install drupal/jsonapi 1.24.0
    - Installation request for drupal/core 8.7.0 -> satisfiable by drupal/core[8.7.0].
    - Installation request for drupal/jsonapi 1.24 -> satisfiable by drupal/jsonapi[1.24.0].

This means you cannot update to 8.7.0 unless removing jsonapi:1.24. However, the release notes says the opposite:

Sites using the 8.x-1.x branch may require changes to API clients, but the contributed module may be left in place with Drupal 8.7 until any needed conversions are complete.


update 8.7

When I try to update database after updating to 8.7 here is the list of changes to do :

menu_link_content module :
  Update custom menu links to be revisionable.

system module :
  Initialize 'expand_all_items' values to system_menu_block.
  Clear the menu cache.   @see https:www.drupal.orgprojectdrupalissues3044364

taxonomy module :
  Update taxonomy terms to be revisionable.
  Remove the 'hierarchy' property from vocabularies.

views module :
  Update exposed filter blocks label display to be disabled.
  Rebuild cache to allow placeholder texts to be translatable.

If I launch the update here is the error message :

Failed: Drupal\Core\Entity\EntityStorageException : Exception thrown while performing a schema update. Impossible de renommer tmp_00d234menu_link_content_revision en                         [error]
menu_link_content_revision : la table menu_link_content_revision existe déjà. dans Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (ligne 1611 de
/home/almedest/public_html/dev/mais/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Cache rebuild complete.    

I try to remove the table "menu_link_content_revision" before to run but it's the same result...

Drupal::currentUser() should give sample code to get the current user entity

The submit button is not following any condition while in popup/dialogs

Hi,

Description of the issue
The form button like the default "Submit" button of any webform, is not accepting any #state conditions once the dialog is initialized.

Problem
The problem is in getting the default state of the button to initialize in the dialog. Because once you start entering input values the button's state is updated.

Why
The issue is Drupal.behaviors.dialog.prepareDialogButtons in core/misc/dialog/dialog.ajax.es6.js clones the primary buttons without copying the #states conditions.

This must be a core States API issue.

Reproduce the issue:

1) Install the webform module.

2) Using the built-in "contact" form, create a condition to hide the "Send message" button.

_ "Hidden" if "Your Name" textfield value is "Hide Button".

the yaml #state condition will be something like:

'#states':
    invisible:
      ':input[name="name"]':
        value: 'Hide Button'

3) Add the "contact" form as a field of type "webform" to the article content type.

4) Create one test article, lets consider the article nid is "12".

5) launch the created article in a dialog/popup using the below code:

<a class="use-ajax" data-dialog-type="modal" href="/node/12">Open article</a>

6) Find the webform field and try to input inside the "your name" field the text: Hide Button

7) You will notice that the "Send message" button is still visible without any changes for its #states.

Reference
The discussion of the webform issue here, lead to create this core issue.

Thank you all for your help and time,

Below is the source code of a configured "contact" form to speed up the reproducing of the issue:

name:
  '#type': textfield
  '#title': 'Your Name''#required': true
  '#default_value': '[current-user:account-name]''#multiple__no_items_message': '<p>No items entered. Please add items below.</p>'
email:
  '#title': 'Your Email''#type': email
  '#required': true
  '#default_value': '[current-user:mail]'
subject:
  '#type': textfield
  '#title': Subject
  '#required': true
  '#states':
    visible:
      ':input[name="name"]':
        value: Webform
  '#multiple__no_items_message': '<p>No items entered. Please add items below.</p>''#test': 'Testing contact webform from [site:name]'
message:
  '#title': Message
  '#type': textarea
  '#required': true
  '#test': 'Please ignore this email.'
actions:
  '#type': webform_actions
  '#title': 'Submit button(s)''#states':
    invisible:
      ':input[name="name"]':
        value: 'Hide Button''#states_clear': false
  '#submit__label': 'Send message'

Forum vocabulary is overridden to required regardless of field settings

Problem/Motivation

Just tried to set a taxonomy term field to non-required in the field UI, and the field persisted as required in the form.

This is because forum_form_node_form_alter() forces the widget to required regardless of the setting. The comment says for 'proper' forum modes, but this occurs for any node type using that vocabulary. The only way I was able to find out what this was happening was because I guessed there'd be an alter in forum module forcing the behaviour, but that was after a few minutes head scratching.

Proposed resolution

Remove the line setting the vocabulary to required to allow the field UI to work as expected.

Remaining tasks

Tagging novice because this should be a one-line patch.

User interface changes

API changes

Data model changes

Release notes snippet

Improve string field sample value generation

Inspiration

I used devel generate for the first time a month ago and here are some problems which I found:

* Taxonomy term names didn't have any spaces in them so it seems they weren't words, but just a random series of characters.
* A varchar / string field I had got immensely long values without any spaces and I doubt any real word could be that long.

This failed to break across lines with word-wrap, broke CSS and caused problems with Search API indexing.

Example: tatramopriclecolumewaclawrephobrushebracripubrunereslepiguuadricridrivopheguvabrubronaspunotistuspimestuchurocichichebadratiharuhabrowuclepheshoviditrohuswatavabradonicipubeuotehotherashewauomupharenadepicriuichokulechisweshoki

Proposed solution

* Generate word-like strings for varchar fields just like node titles.

X-Drupal-Cache-Tags / X-Drupal-Cache-Context header tags can exceed HTTP Server limits and cause WSOD

ORIGINAL TITLE: http.response.debug_cacheability_headers TRUE could cause a WSOD - AH01070: Error parsing script headers

I was getting a WSOD with apache 2.4.29_1 and php-fpm 7.1.14 with the following error:

Premature end of script headers: index.php
AH01070: Error parsing script headers

This was happening on a single URL /node/add/XXX of a CT. The rest worked just fine.

I was finally able to sort it out by setting http.response.debug_cacheability_headers to FALSE on development.services.yml.

I then found out this was also mentioned here on #2827047-15: Add http.response.debug_cacheability_headers: true to development.services.yml.

According to @mpotter on #2827047-16: Add http.response.debug_cacheability_headers: true to development.services.yml:

It is actually very common on complex sites to exceed the Apache header size with too many cache tags, especially when logged in as a user looking at a listing page with lots of nodes that are cached per-user because of node-history.

My site is not that complex. It does use paragraphs and a bunch of fields.

Further research pointed me to http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize

However, attempting to set any of the following to a grater number didn't help (en either main apache conf and vhost conf)

- LimitRequestFields 100
- LimitRequestFieldSize 8190
- LimitRequestLine 8190

The values above are the default, I increased them with different values, I couldn't make it work. I am not sure if I was doing something wrong or anything but it simply didn't allow me to still access the site on that URL.

I can confirm the cache tag length was 8287 bytes on my particular use case.

Notice: Undefined index: #type in drupal_process_states()

Problem/Motivation

Problem

  • When #states is attached to a form element that contains #markup the following notice occurs:

    Notice: Undefined index: #type in drupal_process_states() (line 583 of core/includes/common.inc).

Cause

  • This happens because a #markup element does not require the #type to be set.

Proposed resolution

  1. Fix the PHP notice.
  2. Add a regression (kernel) test to ensure that this bug does not reappear in the future.

Notes

  • There are no PHP/backend tests for #states right now, because the "functionality" on the PHP side is in essence just a json_encode(), so nothing worth to test.

Remaining tasks

  • Make sure patch applies to 8.5.x and 8.6.x as well.
  • Write an unit (kernel) test to ensure that the bug does not reappear in the future.

User interface changes

No.

API changes

No.

Data model changes

No


Add a "Create content type" link to the add content page

Problem/Motivation

New users don't know where to go to add new content types. Everyone starts by clicking on the "content" link in the Toolbar (sometimes, repeatedly) and struggles with this being almost the right place do to what they want. Here's a video of one participant from the Google Usability studies struggling with where to go to add a new type of content and again after hes already been there once, and again a third time.

Proposed resolution

Add a "+ Create content type" action link at the top of the Add content page (node/add) for privileged users

Related Issues

Note that as proposed in comment #54 below, I have separated out the issue of a secondary button on the Content listing page, since there are still UX decisions to be made (including a new UX pattern within the Admin UI), and potentially some larger technical issues to solve, in the hopes that we can see some momentum on this issue.

PageCache caching uncacheable responses (violating HTTP/1.0 spec) + D8 intentionally disabling HTTP/1.0 proxies = WTF

Problem/Motivation

PageCache determines which responses to cache by inspecting the Expires header. (This should be updated to use the Cache-Control header instead, but that's out of scope here.)

Responses that have Expires: Sun, 19 Nov 1978 05:00:00 GMT are meant to not be cached, because it's an expiration date in the past. Yet PageCache caches them permanently:

$expire = ($date > $request_time) ? $date : Cache::PERMANENT;

This has been the case for a very long time, even predating #2527126: Only send X-Drupal-Cache-Tags and -Contexts headers when developer explicitly enables them. Quite possibly the rationale was it's fine to cache uncacheable responses, because cache tags will ensure the responses are invalidated in a timely manner.


Now, to make matters worse, even when you configure a non-zero "max age" at /admin/config/development/performance, \Drupal\Core\EventSubscriber\FinishResponseSubscriber::setResponseCacheable() will still cause that same Expires header to be set? Why? Because when \Drupal\Core\EventSubscriber\FinishResponseSubscriber::onRespond() calls \Drupal\Core\EventSubscriber\FinishResponseSubscriber::setResponseCacheable(), the latter contains this code:

    // HTTP/1.0 proxies do not support the Vary header, so prevent any caching
    // by sending an Expires date in the past. HTTP/1.1 clients ignore the
    // Expires header if a Cache-Control: max-age directive is specified (see
    // RFC 2616, section 14.9.3).
    if (!$response->headers->has('Expires')) {
      $this->setExpiresNoCache($response);
    }

In other words:

  1. Drupal 8 intentionally disables HTTP/1.0 proxies
  2. Drupal 8 ships with a HTTP/1.0 reverse proxy that is breaking the spec: Page Cache

Proposed resolution

Make \Drupal\page_cache\StackMiddleware\PageCache a HTTP/1.1 proxy: make it inspect Cache-Control rather than Expires

Remaining tasks

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

update from 8.6.15 to 8.7 fails due to menu_link_content

I get this error when i try to run the database update:

Failed: Drupal\Core\Entity\EntityStorageException: The entity update process    [error]
failed while processing the entity type menu_link_content, ID: 3. in
Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema-&gt;copyData() (line
216 of
D:\FILES\REPOS\detroitmi-test\docroot\core\lib\Drupal\Core\Entity\Sql\SqlFieldableEntityTypeListenerTrait.php).

Failed while updating from 8.6.15 to 8.7.0

Attemp to update my site from 8.6.15 to 8.7.0 using: composer update drupal/core webflo/drupal-core-require-dev --with-dependencies as always.

All modules are updated to last release and the site with version 8.6.15 was working with no a single error.

After successfully running composer update drupal/core webflo/drupal-core-require-dev --with-dependencies, I tried to update the site from UI,

Available Updates:

system module
8701 - Remove the unused 'system.theme.data' from state.
8702 - Add the 'revision_translation_affected' entity key.
Initialize 'expand_all_items' values to system_menu_block.
Clear the menu cache. @see https:www.drupal.orgprojectdrupalissues3044364
comment module
8700 - Set the 'owner' entity key and update the field.
8701 - Make the 'entity_type' and 'field_name' comment fields required.
Add comment settings.
file module
8700 - Set the 'owner' entity key and update the field.
node module
8700 - Set the 'owner' entity key and update the field.
taxonomy module
8701 - Add an index on the 'taxonomy_term__parent' field table.
Update taxonomy terms to be revisionable.
Remove the 'hierarchy' property from vocabularies.
layout_discovery module
Recalculate dependencies for the entity_form_display entity.
Recalculate dependencies for the entity_view_display entity.
menu_link_content module
Update custom menu links to be revisionable.
views module
Update exposed filter blocks label display to be disabled.
Rebuild cache to allow placeholder texts to be translatable.

while updates are running, and more specifically when the "Post updating layout_discovery", I am receiving the below error:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /update.php/start?id=352&op=do_nojs&op=do
StatusText: OK
ResponseText: TypeError: Argument 1 passed to Drupal\Core\Entity\EntityStorageBase::loadMultiple() must be of the type array or null, string given, called in S:\Sites\dev\web\core\modules\views\src\Plugin\views\filter\EntityReference.php on line 397 in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 256 of S:\Sites\dev\web\core\lib\Drupal\Core\Entity\EntityStorageBase.php).

When I click on the available link: see full error in details, the below messgae displayed:

Notice: Undefined offset: 1 in Drupal\system\Controller\DbUpdateController->results() (line 413 of core\modules\system\src\Controller\DbUpdateController.php).
Drupal\system\Controller\DbUpdateController->results(Object) (Line: 179)
Drupal\system\Controller\DbUpdateController->handle('results', Object)
call_user_func_array(Array, Array) (Line: 115)
Drupal\Core\Update\UpdateKernel->handleRaw(Object) (Line: 76)
Drupal\Core\Update\UpdateKernel->handle(Object) (Line: 28)

The update process was aborted prematurely while running update # in menu_link_content_post_update_make_menu_link_content_revisionable.module.

Any help please ? Thank you

Cannot use relationship for rendered entity on Views

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

  1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
  2. Create and edit a content view.
  3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
  4. The row style plugin is "Content" by default.
  5. Click on "Teaser" in order to change the view mode, nothing happens.
  6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

 

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructionsExtract the test code + yml file out of the patch in #26

composer-based workflow: composer.patches.json is accessible in webroot when using cweagans/composer-patches

When using a composer-based workflow a dependency that is frequently used is https://github.com/cweagans/composer-patches.

This library can be used to patch modules that are downloaded using composer. As the documentation states, you create a composer.patches.json file:

"extra": {
    "patches-file": "local/path/to/your/composer.patches.json"
  }

But I guess a lot of people will place this file in the webroot. This will make this file accessible since the default .htaccess provided by Drupal core will only block composer.json and composer.lock.

<FilesMatch "\.(engine|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl(\.php)?|xtmpl|yml)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock))$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$">

This makes it possible to view all patches that are applied to your project.

Taxonomy Index for unpublished entities

Is there a reason hook_field_update doesn't update the taxonomy index for unpublished entities? I have a use case where editors can manipulate the taxonomy terms of unpublished nodes but these updates aren't inserted into the taxonomy index table. This makes it a challenge to create a view that searches unpublished nodes by taxonomy term name (as opposed to tid, which can be search by taxonomy_field_name_instance)

This would be trivial to patch as it is just an if statement in line 501 of field.api.php.


Multi level (multirow) header for table FAPI element

Problem/Motivation

Drupal's theme system does not support tables with more than one row of table headers. Browsers support rendering multiple table headers and it can be useful for grouping/hierarchies of table header cells.

The idea of this feature request is to let users build table via the FAPI just as it was until then, but also to allow them to add one more depth level and let them build complex table header.

Further info:
http://jsfiddle.net/7pDqb/
http://stackoverflow.com/questions/18680044/how-can-i-construct-a-table-...

Proposed resolution

Update template_preprocess_table() method to let analyse headers with one more depth level, in a backward compatible way.
Update all table.html.twig files to reflect this change and support multiple rows of table headers.
Build a test to show the new feature and keep existing table test to show it's backward compatibility.

This would result in the ability to create this kind of headers via FAPI:
Image may be NSFW.
Clik here to view.
Complex header table

Remaining tasks

Design a solution and implement it.

User interface changes

none.

API changes

'#type' => 'table' FAPI element will support multiple row headers, that means the 'header' key would allow a one more depth level.
It may request another speical key to be achieved, but the exact API changes have to be discussed during implementation.

Core Mail class prints non-overridable errors on the page

Problem/Motivation

1) User interface

While working on issue #2348119 , it was noticed that the core MailManager->mail() , when encountering a problem with passing the mail on to the mail server, logs the error and then uses drupal_set_message() to tell the visitor about it.

It already returns an array that contains the outcome of the attempt, which can be then handled by the caller.

This causes problems for modules that want to provide better errors to the user ( e.g. in the case of the contact module, which mail failed instead of all of them individually ).

The first idea was to extend the class when wanting to override this behavior, but that leads to duplicating the entire function minus a line.

2) Running from cron

A common setup is to use crontab to schedule drush cron via drush. If drush detects any error messages from messenger()->addError, prints them and returns an error to the shell. Depending on the exact config, this might trigger cron to send an emergency mail. So a single email failing to send is being given the same level of urgency as a major problem such as the overnight backup failing.

Simplenews module sends emails in bulk to newsletter subscribers using cron. There appears to be no way for the module to avoid this unwarranted highly-visible false alarm without a change to core.

Further context

For the default PHP mailer, a successful result means "nothing more than the message being accepted at php-level, which still doesn't guarantee it to be delivered". Hence an error result typically indicates a fairly serious general problem.

Alternative mail-sending plug-in implementations can return an error much more easily. In particular Swiftmailer sending over SMTP does so for a bad email address. On a busy site with lots of subscribers, such errors are likely to occur daily.

Proposed resolution

  • D8 Provide an option to control whether MailManagerInterface->mail() displays a message.
  • D9 Remove the option and MailManagerInterface->mail() never a message - this is the caller's responsibility.

Remaining tasks

None.

User interface changes

User will see less (and hopefully more targeted and specific to the action at hand) messages.

API changes

New optional parameter to MailManagerInterface->mail().

The website encountered an unexpected error.

Hi, I have a problem. My website not working. I dont know why. Yesterday, was all good. I didnt do anything on it.
My error

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'www.mysafety.pl.semaphore' doesn't exist: SELECT expire, value FROM {semaphore} WHERE name = :name; Array ( [:name] => variable_init ) in lock_may_be_available() (line 167 of /var/www/html/mysafety.pl/includes/lock.inc).

I tried to clear register
https://www.drupal.org/project/registry_rebuild
but i haven't folder "registry_rebuild".

I checked in my database this table "semaphore" and it is in the database, although the error states that it doesnt exist
I do not know what to do. It is very urgent.
Please help me.

Version:
PHP 5.2.4
Drupal 7.53

Support third party settings for components within a section

There's an issue to support adding third party settings to sections: #2942661: Sections should have third-party settings, but it would be great to also support third party settings for individual components (blocks) within a section.

For example, modules like Block Class and Field Formatter Class use third party settings on block config entities to allow the user to add arbitrary CSS classes to a block. It seems that the only way to do this with a Layout Builder block is to modify the settings form for the individual block plugin you want to modify and store the configuration along with the other configuration for that block.

Create "scripts" element to align rendering workflow to how "styles" are handled

This patch modifies the way Javascript <script> tags are handled.

It defines a new element type "scripts", and this new element has a new #pre_render callback drupal_pre_render_scripts, just like the element "styles" and drupal_pre_render_styles for CSS files.

By doing this, we align the "scripts" element with the "styles" element.

Viewing all 296290 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>