API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
> array|bool The table field mapping for the given table or FALSE if not available.
That leads you to believe that the return is the same as what you get from $storage->getTableMapping()->getAllColumns($table). But it's not -- the array is flipped, so keys are field names and values are just incrementing integers.
This is a port of #2764221: utf8mb4IsSupported() shouldn't guess that InnoDB is the default engine to Drupal 8.
Whever I try the upgrade, it hangs at 38%. Checking the error log, I see multiple entries with the message "Missing filter plugin: filter_null."
I know that the PHP plugin was enabled on the old site, so not sure if it's related to that. I did try enabling the contrib version of the D8 PHP filter, but php still showed up as a missing dependency, and there was no change in the import.
Hey folks. Any idea on where to start looking to debug the following? I'm getting this on one of my sites after the 8.5.0 upgrade. I tried disabling all my contrib modules, yet this error still persists.
[Thu Mar 08 09:41:03.880667 2018] [:error] [pid 22584] [client 69.162.124.237:24151] Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_default' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision\nFROM \n{block_content} base\nINNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array\n(\n)\n" at /var/www/drupal8/www.MYSITE.com/public_html/core/lib/Drupal/Core/Database/Connection.php line 686, referer: http://www.MYSITE.com/
For weeks, tons of notices/warnings like the following in the Drupal watchdog:
472306 25/May 11:29 php notice Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module). 472305 25/May 11:29 php notice Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module). 472304 25/May 11:29 php warning Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 472303 25/May 11:29 php warning Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc). 472302 25/May 09:33 php warning Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 472301 25/May 09:33 php warning Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc). 472300 25/May 09:08 php notice Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module). 472299 25/May 09:08 php notice Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module). 472298 25/May 09:08 php warning Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc).
Looking at the requests from the web server logs, these entries look to be due to attempts to exploit SA-CORE-2018-002 and SA-CORE-2018-004. The fixes for those vulnerabilities should handle things more gracefully and not give notices/warnings, right?
All these notices/warnings for normal operation are masking notices/warnings the administrator may want to observe.
The ability to save forward revisions was added in #218755: Support revisions in different states and—while it is not utilized by Core's UI—contrib modules are now able to save new draft revisions without unpublishing the currently published revision, or implementing unwieldy hacks. However, in the discussion of #2429153: On node revision overview, use 'Set current' if revisions are newer than current version it was indicated that there is currently no officially supported mechanism in Core to set a forward revision to be the current revision. This seems like a major oversight.
The expectation for any module implementing content moderation is that a forward revision can be simply set as the default (a.k.a. "current") revision, without creating a new revision, or changing the content of said revision. It seems like this should be possible by loading a forward revision and saving the entity, setting $newRevision = FALSE and $isDefaultRevision = TRUE. However, this method does not appear to be documented, or included in any tests, so it's function and support is questionable.
Either confirm that the above method is the official way to set a forward revision as the default revision and create tests to enforce that behavior, or provide an alternate method to set a forward revision as the default revision. However it is accomplished, this should update the base tables for the node and its associated fields to reflect the more current revision, without creating a new revision.
Do all the things.
Core does not currently utilize forward revision functionality, so no changes to the UI are anticipated. However, it may impact how #2429153: On node revision overview, use 'Set current' if revisions are newer than current version is implemented.
New tests are needed, but at this time no changes to the underlying API are anticipated.
When attempting to use a link with array parameters that have an integer key, the link processed will be incorrect.
Steps to reproduce
In a fresh installation, add link field to article content type.
Add new article and fill the link field with this example "/exampleview?param[89]=89". Save and view the node.
You will see this link "http://domain/exampleview?param%5B0%5D=89¶m%5B1%5D=89".
I'm expecting this link "http://domain/exampleview?param%5B89%5D=89".
Why am I trying to use this link?
It is a link to a view to pre-select a multiple filter (checkboxes).
Use mergeDeepArray with preserve_integer_keys to TRUE instead of mergeDeep.
The following PHPUnit tests in the Options module extend a Simpletest base class (\Drupal\field\Tests\FieldTestBase):
\Drupal\Tests\options\Functional\OptionsDynamicValuesTestBase\Drupal\Tests\options\Functional\OptionsFieldUITest\Drupal\Tests\options\Functional\OptionsFloatFieldImportTest\Drupal\Tests\options\FunctionalOptionsWidgetsTestAccording to the instructions at #2735005: Convert all Simpletest web tests to BrowserTestBase (or UnitTestBase/KernelTestBase), these tests should extend the new version \Drupal\Tests\field\Functional\FieldTestBase:
Any TestBase or Trait which is in the old /src/Tests/ location should remain there and be deprecated. Copy the TestBase or Trait file into the new location and alter the tests to use the new version. The deprecated class must not "use" the newly-moved class, but remain exactly as it is. Create a change record for the deprecation notice - one CR can cover all deprecations within a module.
Update the tests to extend the PHPUnit based \Drupal\Tests\field\Functional\FieldTestBase
None.
None.
None.
I don't really know if this is a core issue or block cache alter issue... even I don't know if it there is any solution...
I have a website with both "User login" block and "Search" block, cached with "Globally cached" option. But when using cache on that blocks, I get duplicated ID's (i.e., #edit-submit and #edit-actions). I think it's because admins don't see "User login" block, so "Search" block HTML gets cached with #edit-submit ID. Then, when first anonymous visitor comes to the site, "Search" block HTML gets loaded from cache, and "User login" block it's dinamically generated with #edit-submit ID (because it wasn't generated dinamically before). So, the HTML generated can't be validated by automatic tools.
This also can generate bugs in javascript, and stylesheet problems (luckily for me, it's not my case).
Is there any way to avoid this? Storing somewhere IDs cached used when caching or something...
As I said, I don't know if this is a core issue or not.
This is a part of #2960253: [meta] Allow Paragraphs widget/field and similar use cases to to be considered translatable which is being split into 3 separate issues and converted to a meta issue.
* First we need to get around the fact that \Drupal\content_translation\ContentTranslationHandler::entityFormSharedElements() is hiding our widget on the form. I found a workaround for that, but I think it would be easier if widgets could just set #multilingual themself and content_translation_form_alter() would not override it. This might also help with some hacks we have right now to get rid of the translatability clue message.
Respect an already set key in content_moderation_form_alter(). This is a minimally invasive change. There is already #1498724: Introduce a #multilingual key (or similar) for form element to make that property more official and document it.
None unless someone sets the #multilingual property in a widget.
No change unless someone would have already before tried to set that key which is very unlikely.
None.
Follow-up #2853359: Runtime debug statement in Views now prints out object:
@Lendude:
Printing debug information on a live system feels wrong. Looks like Views is the only place in core where this currently happens outside of tests, so should we maybe take them all out?
\Drupal\views\Plugin\views\field\FieldPluginBase::addAdditionalFields
\Drupal\views\Plugin\views\style\Opml::render
\Drupal\views\Plugin\views\style\Rss::render
\Drupal\views\Plugin\views\style\StylePluginBase::render
@dawehner
This code is probably coming from Drupal 6, where exceptions weren't really a thing, given views was compatible with php 4.
@Lendude
IMO debug statements should not live in core code and as @dawehner pointed out in #11, this is probably a leftover from D6/PHP4 times, so it could do with an update to more current best practice.
debug() has worked its way (for live in core code), and is no longer the best practice.
We have also few other problem with debug:
The changes in content_moderation/translation and how it handles non-translatable fields broke paragraphs pretty badly. See #2951436: Fix integration with content moderation in multi-lingual scenarios, based on some reports we saw, it also affects non content-moderation workflows (as in, non-workflow workflows. Excuse the bad wordplay, it is late).
The thing with paragraphs is that we display references entities, which have their own revisions and translations in the same form. The field itself is untranslatable (at least that's currently the only supported mode), and we lock down all changes that would result in a change on the field itself, to make sure referenced paragraph id/revision id and order can not change across translations. But we do allow the change the corresponding translations and revisions in the referenced paragraphs and their fields.
A lot of that keeping-in-sync stuff happens directly in Entity Reference Revisions which supports the concept of "composite entities" that only exist in the context of a parent and automatically get a new revision if the parent does.
That means we're technically compatible with the limitations that core has on non-translatable fields, the logic in content_translation/entity storage just doesn't know about it because all it knows is the isTranslatable() flag on the field.
There are a few steps that are necessary here to make things work. Per discussion in this issue, each problem has been moved to a separate issue.
* First we need to get around the fact that \Drupal\content_translation\ContentTranslationHandler::entityFormSharedElements() is hiding our widget on the form. I found a workaround for that, but I think it would be easier if widgets could just set #multilingual themself and content_translation_form_alter() would not override it. This might also help with some hacks we have right now to get rid of the translatability clue message.
#2975754: Add hooks to acton on a new revision being created
* Then we need to prevent the field from being replaced with the default revision/translation values in \Drupal\Core\Entity\ContentEntityStorageBase::createRevision().
#2826021: FieldItemList::equals is sufficient from the storage perspective but not from the perspective of ContentEntityBase::hasTranslationChanges
* While we don't want the paragraph field values to be replaced, we basically need to be able to apply the same/similar logic to our referenced entities. So when a new "merge-revision" of the node is created, we want to do the same to the paragraphs, so that they too merge their translatable/untranslatable fields together. And later on when we have fancy conflict resolution that will replace this special case, we'll need to be able to apply that recursively as well.
#2975762: Respect existing #multilingual property in content_translation_form_alter()
This is a part of #2960253: [meta] Allow Paragraphs widget/field and similar use cases to to be considered translatable which is being split into 3 separate issues and converted to a meta issue.
* While we don't want the paragraph field values to be replaced, we basically need to be able to apply the same/similar logic to our referenced entities. So when a new "merge-revision" of the node is created, we want to do the same to the paragraphs, so that they too merge their translatable/untranslatable fields together. And later on when we have fancy conflict resolution that will replace this special case, we'll need to be able to apply that recursively as well.
Add hook_entity_revision_create() and hook_ENTITY_TYPE_revision_create()
None
Two new hooks, no changes.
None.
There are might be use cases in custom/contrib where we have to take a different decision depending on if we are comparing a field item list from within ContentEntityStorageBase::hasFieldValueChanged, ContentEntityStorageBase::populateAffectedRevisionTranslations or from within ContentEntityBase::hasTranslationChanges.
ContentEntityStorageBase::hasFieldValueChanged needs to compare only the values that are saved to the storage that would be target_id only in case of entity references.
ContentEntityStorageBase::populateAffectedRevisionTranslations and ContentEntityBase::hasTranslationChanges on the other side might need much more complicated decisions to be made e.g. in our system we have translation changes on a entity reference field if the referenced entities have been changed which we are mainly using for inline editing. In this case FieldItemList::equals is not sufficient because of two reasons:
1. We are not able differentiate wherefrom the function is called.
2. We do not know the language for which it is called in case of not-translatable field but ContentEntityBase::hasTranslationChanges might still wanna compute differences only for entities of a specific language as when the parent is rendered its references are retrieved in the current language of parent.
To solve the problem we introduce a new method FieldItemListInterface::hasTranslationChanges which has two parameters - one for the list to compare against and one for the language to consider. This new method will by default just call ::equals, but to give more developer possibilities the new method will be called to compare the lists from within ContentEntityBase::hasTranslationChanges instead the equals.
Review, Change Record, Commit.
None.
New method FieldItemListInterface::hasTranslationChanges.
None.
watchdog() (in includes/bootstrap.inc, not watchdog.module since we no longer have such a module) should be able to avoid invoking hook_watchdog() implementations when the level of the event is lower than a system-defined logging level, i.e. with a WATCHDOG_* constant higher than this level, due to the actual values of these constants.
This would reduce some long-standing performance issues with useless logging. Without going into per-source or per-implementation settings, and without defining a UI, it could be made 100% compatible with the current situation while still fixing this bug:
- define a watchdog_minimum_level variable in settings.php, defaulting to WATCHDOG_DEBUG to keep all events by default
- only invoke the hook for events above that level
That way existing code would not be affected, but sites with watchdog chatter issues could reduce the "noise" and increase performance.
So this is pretty edge case, but I recently found an issue with the core .htaccess redirect for install.php. I recently migrated a coding blog to Drupal 8 and found a problem where an article was trying to redirect to the install system, but failing. Essentially, any path that contains the string "installphp" with redirect to install.php. This is the same for rebuild.php.
Running a few tests shows this effect.
/install.php (301) redirects to /core/install.php
/core/install.php does not redirect
/something-install-php does not redirect
/something/install.php (301) redirects to /something/core/install.php
/install-php (301) redirects to /core/install-php
/something/install-php-something (301) redirects to /something/core/install-php
/something/install-php-something (301) redirects to /something/core/install-php
/something/install/php/something (301) redirects to /something/core/install/php
Essentially, the section in the .htaccess file that deals with install.php and rebuild.php should have the '.' escaped in the redirect rule.
# Redirect common PHP files to their new locations.
RewriteCond %{REQUEST_URI} ^(.*)?/(install\.php) [OR]
RewriteCond %{REQUEST_URI} ^(.*)?/(rebuild\.php)
RewriteCond %{REQUEST_URI} !core
RewriteRule ^ %1/core/%2 [L,QSA,R=301]Re-running the above tests show this fixes the redirects in most situations.
/install.php (301) redirects to /core/install.php
/core/install.php does not redirect
/something-install-php does not redirect
/something/install.php (301) redirects to /something/core/install.php
/install-php does not redirect
/something/install-php-something does not redirect
/something/install-php-something does not redirect
/something/install/php/something does not redirect
I'm not sure how to go about adding tests for this into core, mainly because this is largely a Apache issue. Happy to help if any are needed.
From looking at the commit history it looks like this redirect was added with issue https://www.drupal.org/project/drupal/issues/2097189. This produced the core patch https://cgit.drupalcode.org/drupal/commit/?id=52d3b49336b.
Follow-up of #1174892: File field formatters for rich media display with <video> and <audio> HTML5 elements..
Quite often sites use remote audio/video files (e.g. on S3 or so), so it might be useful to also allow those formatters on link fields.
Obviously a bit tricky from UX perspective as it will only work if the provides urls are valid video/audio files.
Related contrib issue: #2927099: Support audio streams
The current Media administration experience is not very visual, and does not look like what most people expect from a CMS.
We should update the view at /admin/content/media to look more modern - displaying a grid of media cards that show a preview of the media and metadata (attributes/fields) that make sense for each media item.
To give more flexibility to site builders and themers, each media item in the library is rendered in a new view mode called "Media Library", which is customizable like any other view mode.
This updated view will also be the basis for a new Field Widget, to allow visual selection of Media while editing/creating content. This widget will be added in another issue, but part of why this is being added in a new experimental module is to have a place for us to iterate on the widget and other code related to the Media Library experience.
Review the current patch. Discuss UX feedback.
Note for committers - on commit, please ensure that "jan.stoeckler, webflo, seanB, chr.fritsch, DyanneNova, yoroy, dennis-cohn, rfmarcelino, andrewmacpherson, benjifisher" is added to the issue credits. This is ported over from #2834729: [META] Create an MVP for adding and re-using Media.
The view at /admin/content/media looks different, but is functionally the same.
None.
None.
Suppose you have some content entity type (foo) with an entity reference to nodes, and you have contrib or custom code that needs to update something about the referenced nodes whenever the host entity is updated. So you implement hook_foo_presave() or hook_foo_update(), and in that function you load the referenced nodes, do something to them, and save them.
By design, all of this happens within a single database transaction: SqlContentEntityStorage::save() starts the transaction prior to invoking hook_foo_presave() and doesn't commit the transaction until after all hook_foo_update() implementations complete.
Meanwhile, when the first child node is saved, Entity::invalidateTagsOnSave() invalidates several broad tags ('node_list' and '4xx-response') that are not specific to the particular node, which causes DatabaseCacheTagsChecksum::invalidateTags() to send a merge (UPDATE) query to the corresponding records in the {cachetags} table.
This causes the database engine (e.g., InnoDB) to acquire a row lock on those records, which it doesn't release until the end of the transaction. However, if there are more child nodes that need to be saved, or other slow hook implementations that need to be performed, prior to the end of the transaction, then these locks could last 10, 20, or more seconds.
Now suppose you have concurrent users editing foo entities on this site. Even if they're editing different foo entities with different child nodes, they all end up competing for the same lock on the 'node_list' cache tag. Depending on how long they each need to wait, this could end up appearing as a deadlock, or in some cases, even lead to real deadlock.
Change DatabaseCacheTagsChecksum to delay updating the database with cache tag invalidations until just before the end of the transaction. However, also have its isValid() return FALSE while there are not-yet-committed invalidations. This way, other requests continue seeing the old value until the end of the transaction (which is already the case in HEAD, since that's how transactions work), while later code in the same request (e.g., other presave/update hooks) continues to see the invalidation as having already occurred (just as in HEAD).
If done right, I think this is fully backwards compatible, while reducing to practically 0 the time that a {cachetags} record lock is held.
None.
A public method addition to Drupal\Core\Database\Connection for adding callbacks to run just prior to transaction commit.
API page:
https://api.drupal.org/api/drupal/core%21core.api.php/function/hook_conf...
The example code is not correctly formatted -- it uses < code > tags instead of @code