Field storage and entity type CRUD operations (e.g. install a new field in an update function, delete an entity type in an update function, etc.) need the ability to initialize a table mapping "on demand", mostly because they need to work with the last installed definitions instead of the ones living in code.
This is currently done by switching the entity type definition in the storage itself just for the duration of the CRUD operation, which is a "documented hack" with tons of @todos saying "fix this in #2274017: Make SqlContentEntityStorage table mapping agnostic ".
Proposed resolution
- Move the table mapping initialization code from \Drupal\Core\Entity\Sql\SqlContentEntityStorage::getTableMapping to the table mapping itself.
- Make the table mapping aware of the entity table names, and also generate default table names if the entity type doesn't provide them, just like the storage does.
However, that Content-Type HTTP header for feeds coming from views is set way down in template_preprocess_views_view_rss(), which means that information is not cached. Once such a feed (with its relative URLs) is in the render cache, that preprocess hook will not be called for subsequent requests, and so the default Content-Type header will be used, of 'text/html'. This is both wrong, and stops that RssResponseRelativeUrlFilter service from changing the URLs.
Currently Drupal core has a dependency on the Link project. This is because it specifies the link module as a dependency and projects with the same name as the module are preferred.
Currently the automated testing infrastructure (Project Dependency) assumes that Drupal core has no dependencies so the erroneous dependency on the Link project is ignored.
Image may be NSFW. Clik here to view.
It is important for Drupal core to use best practices because contributed projects will follow the example set by core and specifying dependencies in an ambiguous manner may cause problems with automated testing. Also, if in the future Drupal core uses external dependencies it may not always be the case that Drupal core does not have dependencies.
Proposed resolution
Replace all dependencies that are not namespaced with their namespaced versions.
When the layout_builder module is enabled, trying to view a term page crashes with:
Drupal\Component\Plugin\Exception\ContextException: Assigned contexts were not satisfied: entity in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 101 of /var/www/html/web/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php).
In older versions of Firefox, details elements in the Seven theme in Drupal 8.x, such as on admin/config/system/site-information , looked like this screenshot -- the summary line (which is a link to open/close the details area) showed up in blue, with a little triangle open/close icon next to it: Image may be NSFW. Clik here to view.
With current versions of Firefox, however, it isn't so nice. The summary line is black, and the open/close icon is missing: Image may be NSFW. Clik here to view.
This is a big usability problem. It's not obvious without the little arrow or the blue color that this is a link to open/close the box, at least to me.
Proposed resolution
After some debugging, the problem was traced to the normalize.css file [see original issue summary in first comment for details]. We are currently using a 3.x version of the Normalize library, and it has "summary" elements with display: block;. The current version of the Normalize library uses display: list-item; instead.
So, we need to either:
a) Update to the current version of normalize. This option was rejected by the core maintainers in comment #13, and has been moved to its own issue: #2821525: Update normalize.css to 7.0.0
b) Add a small bit of CSS to our normalize library to override display: block for summary elements. That is what is in the current patch.
Remaining tasks
a) [done] Figure out what to do [Make a small patch to add CSS to override that one piece of the normalize library].
b) [done] Make a patch.
c) Test the patch on multiple browsers:
- Firefox - works - tested in comment #20
- Chrome - works - tested in comment #22
- Safari - works - tested in comment #25
Novice task:
- Apply the patch on a local Drupal site. It doesn't really matter which version of Drupal you are using.
- Clear the cache.
- Visit a page like admin/config/system/site-information , using the current version of a browser that has not yet been tested (see Proposed Resolution section, above this in the issue summary).
- See if the summary lines on details elements are formatted correctly (with the drop-arrow) or not.
- Make a screenshot similar to the ones in comments #20 and #22.
- Add a comment telling which browser you tested, and upload your screenshot in the Files section.
User interface changes
Details elements on admin pages will again have the drop-down arrow applied to them in current versions of Firefox. Right now they don't and it's rather confusing UI.
When creating a new custom field type, extend the class fileItem for the new custom field type.
Go to content type add custom field type created and save, the website encounters an error
TypeError: Argument 1 passed to Drupal\Core\Config\Entity\ConfigEntityBase::calculatePluginDependencies() must implement interface Drupal\Component\Plugin\PluginInspectionInterface, null given, called in core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php on line 388 in core/lib/Drupal/Core/Plugin/PluginDependencyTrait.php on line 27
In #2205271: Project namespace for dependencies support was added to allow modules to list dependencies by prefixing their names with their project name, thus solving the age-old problem of module names and project names being different (*cough* CCK *cough*). This API improvement was included in v7.40.
In #2844504: Testbot failing for Metatag-D7 =) it was identified that some of Metatag's tests were failing because the testci system was unable to download certain dependencies, specifically one submodule depending upon another submodule would fail if the dependency was listed in the old [module] syntax, it had to be listed in the newer [project:module] syntax.
Hook up the codebase to the local web server and try to run the installer.
The following requirements error will be reported:
Required modules - Required modules not found.
The following modules are required but were not found. Move them into the appropriate modules subdirectory, such as sites/all/modules. Missing modules: Drupal:system, Ctools:ctools, Token:token
Further, if the dependency line in panopoly.info is changed to "dependencies[] = metatag:metatag" then the error becomes the following:
Required modules - Required modules not found.
The following modules are required but were not found. Move them into the appropriate modules subdirectory, such as sites/all/modules. Missing modules: Metatag:metatag
It seems like the dependency logic does not properly handle the [project:module] logic for modules available in the current codebase.
Looking at the code I am not sure what is done with external js files like this.
the locale.inc file is:
function _locale_parse_js_file($filepath) {
global $language;
// The file path might contain a query string, so make sure we only use the
// actual file.
$parsed_url = drupal_parse_url($filepath);
$filepath = drupal_realpath($parsed_url['path']);
// Load the JavaScript file.
$file = file_get_contents($filepath);
At https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_... api.drupal.org on drupal.parse.url states:
This function should only be used for URLs that have been generated by the system, such as via url(). It should not be used for URLs that come from external sources, or URLs that link to external resources.
At the moment every contrib module that needs to add/alter tree manipulators require to override Drupal\system\Plugin\Block\SystemMenuBlock (or implement their own).
Drupal 8 includes Symfony's mbstring polyfill which means that core's Unicode library never using this the non mbstring code path. This makes the static set in Unicode::check() complete redundant and its default value wrong. This impacts unit and kernel testing as this then uses the non mbstring code path when no real site ever uses it.
Proposed resolution
Remove the status static from Unicode
Remove the non-mbstring code path from Unicode - it is never used
Remove the need to call Unicode::check to set anything
Fix bootstrap.php to normalise unit and kernel test environments
Fix Unicode::check() so that unicode_requirements() can actually recommend installing the mbstring extension
How to generate most of the patch
# Apply the smaller not tested issue patch from https://www.drupal.org/project/drupal/issues/2849669
# Replace the occurrances including FQDN. Check core/lib/Drupal/Core/Mail/MailFormatHelper.php.
find ./core -type f -not -path "./core/node_modules/*" -not -path "./core/assets/*" -not -path "./core/misc" -exec sed -i -r 's/\\?(Drupal\\Component\\Utility\\)?Unicode::(substr|strlen|strtoupper|strtolower|strpos)/mb_\2/g;' {} \;
# Revert unnecessary changes
git co core/lib/Drupal/Component/Utility/Unicode.php
git co core/tests/Drupal/Tests/Component/Utility/UnicodeTest.php
# Fix unused uses
composer run-script phpcbf -- --sniffs=Drupal.Classes.UnusedUseStatement,PSR2.Namespaces.NamespaceDeclaration
# Apply the smaller not tested post script issue patch from https://www.drupal.org/project/drupal/issues/2849669
Remaining tasks
doit
User interface changes
none
API changes
Deprecate Unicode::setStatus() since this existed for testing purposes only and the static it sets is removed.
Data model changes
none
Original issue summary
Problem/Motivation
KernelTestBase does not provide an environment consistent with a booted DrupalKernel since the locale is not set and by default the use of mb string functions is disabled.
This has been manually worked around in some tests like \Drupal\Tests\token\Kernel\FieldTest::testTokenViewMode()
This was causing unexpected test fails for me when writing new core kernel tests that depend on Drupal correctly lowercasing unicode characters.
Proposed resolution
Copy this code from \Drupal\Core\DrupalKernel::bootEnvironment()
and add it to \Drupal\KernelTests\KernelTestBase::bootEnvironment()
// Set sane locale settings, to ensure consistent string, dates, times and
// numbers handling.
setlocale(LC_ALL, 'C');
// Detect string handling method.
Unicode::check();
Steps to reproduce:
1. Install Drupal 8.5.x (8.5.1 in this case, was working fine before 8.5)
2. enable Language, Content Translation, Content Moderation, and Workflows modules
3. add another language, like French
3. enable content translation on Basic Pages
4. add Default Comment field to Basic Pages (not via "Existing Fields")
5. add the Editorial workflow to Basic Pages
5. create an English Basic Page
6. translate that Basic Page and try to save
Expected behavior:
The node saves.
Current behavior:
You get an error saying "Non-translatable fields can only be changed when updating the original language."
Current Work-around:
Edit Baic Page Comment field and check the "Users may translate this field" checkbox. Now your Translation will save.
Issues:
* The error is not very clear and if your dealing with more than a few fields (like 50) this can take quite a while to debug
* Doing the above steps in a different order (say adding the comment field first, then enabling translation, or adding the existing Comment field) will not trigger the error as the checkbox get automatically ticked when following this order
Proposed Solutions:
(a) remove the "Users may translate this field requirement" for comment fields. After all, what does it mean that users can translate this field? It is not the ability to translate comments, or field meta-data like title and description. This field merely binds a type of comment to a type of node, right?
(b) Have a better error message telling users what field is the offender in the error message (or in Drupal logs)
