The Drupal.Message.defaultWrapper() removes class="hidden" from the fallback div by using wrapper.removeAttribute('class'); which prevents adding classes needed for styling on the wrapper element.
Replace wrapper.removeAttribute('class') with wrapper.classList.remove('hidden').
Very similar to this issue #3094397: Attributes key missing hash or pound sign in seven, it appears another hash is missing in the same file (seven.theme), a few lines down. When attempting to add a remote video to a field, User error: "0" is an invalid render array key in Drupal\Core\Render\Element::children() was showing up the dblog several times.
Adding the hash here $form['#attributes']['class'][] = 'media-library-add-form--oembed'; stopped the error from appearing.
Steps to reproduce:
On a Drupal 8.8 site, create an entity reference field (media) that allows remote video. Add the field to a content type. Create a node of that content type and attempt to add a remote video to the field you made. Look at the dblog to see the error.
What behavior were you expecting?
I was expecting there to be no errors in the dblog.
What happened instead?
Several php errors appear in the dblog every time an attempt is made to add a remote video to this field.
I have a patch that adds the missing hash.
Edited to add: this is the first time I've created a patch and am clearly getting the comment numbers wrong. If this is an issue, please let me know and I can fix.
Dropbuttons in tables are not positioned correctly because of various table cell alignments.
For example: /admin/structure/display-modes/view
We would probably something more like this:
Migration source d7_field_option_translation makes error:
SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'type': SELECT COUNT(*) AS expression
FROM
(SELECT DISTINCT fc.*, i18n.*, lt.*, fci.entity_type AS entity_type, fc.type AS type, fci.bundle AS bundle, i18n.lid AS i18n_lid, i18n.type AS i
18n_type, 1 AS expression
FROM
{field_config} fc
INNER JOIN {field_config_instance} fci ON fc.id = fci.field_id
LEFT OUTER JOIN {i18n_string} i18n ON i18n.type = fc.field_name
INNER JOIN {locales_target} lt ON lt.lid = i18n.lid
WHERE (fc.active = :db_condition_placeholder_0) AND (fc.storage_active = :db_condition_placeholder_1) AND (fc.deleted = :db_condition_placeholde
r_2) AND (fci.deleted = :db_condition_placeholder_3) AND (fc.field_name NOT IN (:db_condition_placeholder_4, :db_condition_placeholder_5, :db_co
ndition_placeholder_6, :db_condition_placeholder_7)) AND (i18n.textgroup = :db_condition_placeholder_8) AND (objectid = :db_condition_placeholde
r_9)) subquery; Array
(
[:db_condition_placeholder_0] => 1
[:db_condition_placeholder_1] => 1
[:db_condition_placeholder_2] => 0
[:db_condition_placeholder_3] => 0
[:db_condition_placeholder_4] => title_field
[:db_condition_placeholder_5] => name_field
[:db_condition_placeholder_6] => description_field
[:db_condition_placeholder_7] => subject_field
[:db_condition_placeholder_8] => field
[:db_condition_placeholder_9] => #allowed_values
)
because field_config and i18n_string tables have type columns.
Drupal 9 will once again allow hook_update_N() to be used between major versions.
However, database updates still regularly introduce bugs, since they often run up against issues on real sites, such as corrupted data, or incompatibilities with contributed and custom schema changes/additions. Also sites that run into upgrade path issues and report them to the issue queue are not always run by people who can debug upgrade path issues themselves.
Remove all updates added prior to Drupal 8.8.0-rc1 from Drupal 9.
This will mean that sites still on Drupal 8.7 or lower, will need to update to Drupal 8.8.0 or later, prior to updating to Drupal 9.
There are various advantages to this:
1. Old upgrade path bugs from Drupal 8.5/8.6 can no longer be fixed in Drupal 8.7 but they can still be backported to Drupal 8.8. Therefore for sites running out of date core versions, getting them onto 8.8 first means they have the best chance of a smooth minor upgrade path before the major one.
2. Old updates may rely on deprecated APIs that are being removed in Drupal 9, and re-writing upgrade paths risk introducing new regressions.
3. Ensuring that every Drupal 8 site is on Drupal 8.8 or 8.9 before they update to Drupal 9 will drastically reduce the variables when upgrade paths are reported (compared to letting people update from Drupal 8.4 to Drupal 9 directly).
4. Contributed modules will also need to be updated to their latest versions prior to moving to Drupal 9, so ensuring core installs do this is encouragement to update contrib too.
Create a patch
None
None
None
Drupal 8 upgrade path has been removed.
Local task labels are always displayed using the content language, ignoring that users can set their admin language preference (if the site has an admin language preference option set in negotiation). Local task label should honor this config and use the admin interface language. Even if they are in a non-admin pages, they are part of the admin interface.
This is very similar to what is being done in #2313309: Admin toolbar should always be rendered in the admin language (if set), but for local tasks. It's worth to note that in that issue current patches seems to translate Contextual Links as well (if not, probably a new issue should be created).
Render local task labels using the admin language config from language negotiation.
Implement it.
Local task labels will be in an admin-appropriate language. Optionally, a checkbox can be added to make this behavior optional.
Likely none.
#2757007: Convert all book web tests to BrowserTestBase uses a method for this, but I believe it should be added to WebAssert. I've already seen similar implementations in contrib.
Add the method to WebAssert.
Testing additions.
Problem:
Using nested paragraphs creates multiple drag handles for sub-paragraph field.
What it looks like:
Steps to reproduce:
1. Create a new paragraph type (sub paragraph) (can be empty without fields)
2. Create two other paragraphs (main paragraphs) (the other one can be empty without fields)
3. Add a Paragraph field to the other main paragraph and include to sub paragraph in the reference type.
4. Add a Paragraph field to basic page and include the two main paragraphs in the reference type
5. Add a basic page and add there the paragraph type which has the sub field. It shows the three drag handles for the sub paragraph
This seems to be an issue in the Claro tabledrag, which has overriden the core tabledrag, because this doesn't happen with Seven administration theme. It seems that the Claro tabledrag.js is adding some wrappers and other divs to the html so that we end up with 3 drag handles. The problem doesn't come up with any other place in admin UI, but the nested paragraphs use the "multiple drag".
The difference seems to be here:
The output for the Seven admin theme:
<td class="field-multiple-drag">
<a href="#" class="tabledrag-handle" title="Drag to re-order">
<div class="handle"> </div>
</a>
</td>And the output for the Claro theme:
<td class="field-multiple-drag tabledrag-cell tabledrag-cell--only-drag">
<div class="tabledrag-cell-content js-tabledrag-cell-content">
<a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
<div class="tabledrag-cell-content__item">
<div class="tabledrag-cell-content js-tabledrag-cell-content">
<a href="#" class="tabledrag-handle js-tabledrag-handle" title="Drag to re-order"></a>
<a href="#" class="tabledrag-handle js-tabledrag-handle menu-item__link" title="Drag to re-order"></a>
<div class="tabledrag-cell-content__item"></div>
</div>
</div>
</div>
</td>It adds the handle three times.
Currently the migrate\process\Log class is only able to log string values, not even NULL are accepted, this is pretty limiting because often the log plugin can be used for quick debug of complex migrations.
The solution is imho simple, if the value is not a string pass it through print_r and store the dumped value.
(patch coming shortly)
Quite a few contrib modules (for example dropzonejs, Content Browser, Select2) have an optional dependency on the Libraries module. They do this do allow the library to placed in locations other than DRUPAL_ROOT/libraries/. For example, on drupal.org distributions wishing to including third party libraries have to use drush make. This places the library in the install profile directory.
Therefore you see a lot of code like:
/**
* Implements hook_library_info_build().
*/
function dropzonejs_library_info_build() {
$libraries = [];
if (\Drupal::moduleHandler()->moduleExists('libraries')) {
$exif_path = libraries_get_path('exif-js') . '/exif.js';
}
else {
$exif_path = DRUPAL_ROOT . '/libraries/exif-js/exif.js';
}
if ($exif_found = file_exists($exif_path)) {
One major problem with this is that libraries_get_path() is deprecated and supposed to be removed in the Drupal 8 (!!!) version of the Libraries module. This has not come to pass but essentially all the modules that are doing something similar to the dropzonejs example above are only using the Libraries module for 1 reason and thats because it searches a defined set up of paths for libraries. This depends on two of its methods - libraries_get_path() and libraries_get_libraries(). Both of these are deprecated with the message:
* @deprecated Will be removed before a stable Drupal 8 release. Please use the
* new library load and managment concepts described at:
* https://www.drupal.org/node/2170763
The link shows that the Libraries module doesn't really want to continue providing this type of functionality and instead was trying to be a registry and had far more expansive D8 ideas. It doesn't appear that these have borne fruit.
There's a lot of discussion about how Drupal should support modules and themes wanting to use other frontend libraries. See #2605130: Best practices for handling external libraries in Drupal 8 for instance.
This issue is not trying to solve the bigger problem.
The proposal here is to search the following paths:
when we encounter a library path like /libraries/dropzone/dist/min/dropzone.min.js. This will allow modules to drop Libraries module integration but maintain the support for third party libraries in multiple locations.
The above search locations are the same as libraries_get_libraries() apart from sites/all/libraries has been removed - and I think the last location found wins so PATH/TO/SITE/libraries> libraries> PATH/TO/INSTALL_PROFILE/libraries
None
None
None
@todo - will need CR to do document the new functionality.
I have upgraded my site to Drupal 8.8, which introduces a new "path_alias" module. However when running drush updb, I get:
...
> [notice] Update started: system_update_8804
> [error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY': INSERT INTO {path_alias} (id, revision_id, uuid, path, alias, langcode, status) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6), (:db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13), (:db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20), (:db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_in
...
In core/modules/block_content/block_content.module, the documentation block for block_content_query_entity_reference_alter() includes the line,
Block_content entities that are reusable should by default not be selectable
It should be "not reusable" rather than "reusable". Compare with the change record Added the ability to set Custom Block entities as non-reusable: it says, in part,
Since a Custom Block with the reusable field set to FALSE should not be reused in other parts of the site the queries of
EntityReferenceSelectionplugins will now automatically be altered to add:$query->condition("$data_table.reusable", TRUE);Unless the query satisfies one of these two conditions:
...
The API documentation for block_content_query_entity_reference_alter() is generated from this documentation block, so I am adding the "API Documentation" tag.
Insert the word "not" and rewrap the affected line and the next to 80 characters.
None, except in the API documentation.
None
None
On a 8.7.7 site I'm building, I'm using core media's video bundles, pointing to YouTube.
If I inspect the filesystem for the actual thumbnails downloaded by YouTube, I see stuff like this:
% identify *
1V7gFNbwKdw.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 102KB 0.000u 0:00.009
4b5n5PVdHpI.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 104KB 0.000u 0:00.000
55n7BFvNqFQ.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 32.2KB 0.000u 0:00.000
R0gFH3_sMGw.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 188KB 0.000u 0:00.000
S3sdd1i9pbQ.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 399KB 0.000u 0:00.000
lzkW7ngYvQo.jpg JPEG 320x180 320x180+0+0 8-bit sRGB 10.4KB 0.000u 0:00.000
n1X73ZyQroE.jpg JPEG 1280x720 1280x720+0+0 8-bit sRGB 127KB 0.000u 0:00.000
pFrani050Zs.jpg JPEG 320x180 320x180+0+0 8-bit sRGB 6.08KB 0.000u 0:00.000
However, {media_field_data} has a totally different idea:
mysql> SELECT mid, thumbnail__width, thumbnail__height FROM media_field_data WHERE bundle = 'video' LIMIT 5;
+-----+------------------+-------------------+
| mid | thumbnail__width | thumbnail__height |
+-----+------------------+-------------------+
| 1 | 180 | 180 |
| 5 | 180 | 180 |
| 15 | 180 | 180 |
| 16 | 180 | 180 |
| 17 | 180 | 180 |
+-----+------------------+-------------------+
5 rows in set (0.00 sec)
Thanks to image_preprocess_image_style(), this results in thumbnail markup like so:
<img src=".../sites/default/files/styles/320x180_small/public/video_thumbnails/S3sdd1i9pbQ.jpg?itok=L8Ug7t3z" width="180" height="180" alt="" typeof="foaf:Image" class="image-style-_20x180-small">
Those width and height attributes are bogus, since the metadata in the DB thinks those are the dimensions of the thumbnail. This results in unnecessarily small thumbnails that don't truly respect the image style as I defined it.
Record accurate dimensions for the thumbnail files in the media entity metadata stored in the DB.
Media thumbnails will know their accurate size/aspect ratio, hopefully resulting in better looking UI in places where media thumbnails are being displayed.
Hopefully none.
None.
TBD
During implementation of a custom entity I debugged the entity reference field autocomplete functionality, as it was not working.
When referencing a new custom entity, the errorThere are no entities matching "Entity label"
pops up.
Beside the right configuration (where different are possible). The code for selecting the bundle is not triggered at all.
There are a lot of tasks open about entity creation. Fe. a user reference field does not work.
The entity reference fields should store they're bundles in auto_create_bundle for "bundle-less" or in target_bundles for ones having multiple bundles.
This issue is thought as quick fix. The remaining task shall be done in subsequent (existing) issues, fe.
#2700411: "Create referenced entities if they don't already exist" option on entity reference field shouldn't be available for users
None.
None.
None.
When setting up a migration with dependencies, I can execute it via the UI. AFAICT it executes the dependencies first and then the main migration script may use migration lookup to grab the dependencies which I believe is correct.
e.g.
migration_dependencies:
required:
- twodareis2do_rss_skysports_pictureHowever when executing via hook_cron, using the above it will complain of missing dependencies. It seems that on occasion I can substitute required with optional, however it would seem that that this seems slightly erratic and will only seems to update sometimes.
Would it be possible to fix this so that cron migration scripts behave as they would to when executed via the UI.
The current markup for Dropbutton looks like this:
<div class="dropbutton-wrapper dropbutton-processed dropbutton-multiple">
<div class="dropbutton-widget">
<ul class="dropbutton">
<li class="edit dropbutton-action"><a href="/admin/structure/views/view/content">Edit</a></li>
<li class="dropbutton-toggle"><button type="button"><span class="dropbutton-arrow"><span class="visually-hidden">List additional actions</span></span></button></li>
<li class="clone dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/clone">Clone</a></li>
<li class="disable dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/disable?token=hQ2egsGF5LtsScdw2oQFeoWNKrUi1HHP9W1WZhjehOk" class="use-ajax ajax-processed">Disable</a></li>
<li class="delete dropbutton-action secondary-action"><a href="/admin/structure/views/view/content/delete">Delete</a></li>
</ul>
</div>
</div>
There's a lot we could do we simplify and improve the markup so it's inline with our CSS coding standards
<div class="dropbutton dropbutton--modifier"> <!-- whole component is dropbutton. -->
<a class="button dropbutton__action">Action One</a>
<button type="button" class="button dropbutton__trigger">
<span class="visually-hidden">List additional actions</span>
</button>
<ul class="dropbutton__menu" role="menu">
<li><a class="dropbutton__action">Action Two</a></li>
<li><a class="dropbutton__action">Action Three</a></li>
</ul>
</div>
Decide on a battle plan of improvements
Write a patch
Test a lot
None
Mark up changes
The node edit form currently has an odd problem in that the publication status field gets lost at the bottom of the edit form. It would make much more sense were it to be moved to the sidebar where it can have some prominence.
When tampering with the page parameter for a view and setting it to a huge size, a mysql error occurs:
Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-6446744073709551616' at line 3: SELECT ...
e.g. http://example.com/myview?page=1e18
Add an integer limit on the LIMIT parameter.
"Convert line breaks into HTML" filter is placing the `drupal-media` tag within a paragraph. It should exclude this tag, as it excludes others, such as `script` and `iframe`.
This is a follow-up issue to #3097338: "Convert line breaks into HTML" filter breaks drupalmedia code that adds edit button.
Add the `drupal-media` tag to the list of tags to exclude.
review, discuss, commit
Several code comments refer to \Drupal\Update\UpdateManager::getProjects(). The correct namespace is \Drupal\update (lower case "update", referring to the Update module).
These comments seem to have been added in #2449809: Remove usage of update_get_projects().
We briefly made the same mistake in a use statement (not a comment) in #3015810: Properly deprecate UPDATE_* constants, but that was promptly corrected.
Search for \Drupal\Update and correct the capitalization. You can use the following command to search:
grep -r '\\Drupal\\Update' core
None
None
None