Follow-up to #1472946-67: Remove usages of deprecated function drupal_realpath() throughout core functions
Deprecated usage was replaced but not all classes using to inject dependency
Inject file_system service into every place where it's possible
- replace usage of \Drupal::service('file_system') with properly injected service
We have committed to trying to support multilingual in demo_umami for the 8.7 release next March.
We need to discuss what language we would like to support, so let's do so in the comments here.
RegisterForm::save handles both saving the user and notify of the new account (if requested). This means you can't do any actions prior to the notification email being sent out that require a user ID.
A good example of this is if you are collecting an alternative display name (say on a profile and using realname or hook_user_format_name_alter()). To do this you need to save the profile with the owner set, which can only happen once the user is stored so it has an ID. Because all of this has to happen afterRegisterForm::save, it's too late to be able to use the preferred display name in the notification email (or any other tokens that you do actually collect on registration).
Additionally, the following piece of code makes me nervous that you may not be able to safely save the user twice, as once saved the password returned from User::getPassword will be hashed, which the comment suggests may cause problems later on:
$pass = $account->getPassword();
...
$account->save();
....
// Add plain text password into user account to generate mail tokens.
$account->password = $pass;
Split the notification logic out into RegisterForm::notify so contrib/custom can insert submission handlers between the two.
None.
If any contrib/custom have worked around they may have to update their code, but I can't think of any workaround that would break with this change.
I store an image here:
DOMAIN_NAME/sites/default/files/images
I then rename the image via FTP (and check the file has definitely been renamed via SSH). I then clear ALL caches via Drupal admin. I then clear browser caches.
Unfortunately, the image is still being displayed, even the the old URL should now not find the image, as it's been renamed.
How to reproduce:
* Go to admin/config/system/site-information
* Into "Default front page" enter a path with querystring, e.g. "/admin/people?status=2"
* Submit
* Go to Frontpage
Expected: See the configured page (here users filtered by "blocked")
Result: "Page not found"
Fix this.
Codeit.
None.
None.
None.
View more link in recipe cards is not fully translated. The bundle is always in English because we are using the bundle machine name.
Use the type label() for rendering the translated type name.
Patch
None (in English), but will make this translatable.
None
None
For a view with a page display and an attachment display, exposed filters are not inherited in attachment display even if 'Inherit exposed filters' option is set to yes.
Using the module filter on the module list page a module can only be found by system name if the description ends in a dot. This is caused by the fact that jQuery's .text() method doesn't add any spaces. Therefore the Regex in Drupal.behaviors.tableFilterByText showModuleRow which uses word boundaries only recognizes the word if the description contains a period to end the sentence and make the machine name its own word.
This is why for example searching for "dblog" works currently but searching for "yoast" doesn't show the Real-Time SEO module in the 8.x-2.0-alpha3 release.
Make the showModuleRow slightly more elaborate by ensuring the values of the different possible search sources are separated by a space.
While working on #2798363: Implement --idlist options on rollback and messages, I noticed some really wild and crazy things going on in the rollback section of the migrate executable. We loop over the id_map, but then never use the row we are looping over. But as a side "benefit" it advances the rows forward.
Let's make the code more extensible and more readable so things like #2798363: Implement --idlist options on rollback and messages can only change a small amount of code, not large hunks of code.
It would be nice, if possible, to backport this to 8.6 as we have a patch (w/ passing tests) in migrate_tools waiting for this feature.
n/a
n/a
n/a
In order to remove calls to deprecated functions, I tried to replace $entity->link() with $entity->toLink() in a config entity.
However, when I did the change, I got this error:
Drupal\Core\Entity\Exception\UndefinedLinkTemplateException: No link template 'canonical' found for the 'config_pages_type' entity type in Drupal\Core\Entity\Entity->toUrl() (line 214 of /path/to/project/web/core/lib/Drupal/Core/Entity/Entity.php).
After some debugging I found that toLink() method was not implemented in Drupal\Core\Config\Entity\ConfigEntityBase during #2606398: Add EntityInterface::toUrl() and EntityInterface::toLink() and mark urlInfo(), url() and link() as deprecated
Given we have the comment line // Do not remove this override: the default value of $rel is different. in ConfigEntityBase::link() I think would be a good idea to add the same implementation of ConfigEntityBase::toLink() to keep consistency.
Add an implementation of ConfigEntityBase::toLink() changing default $rel parameter to give a better support for config entities and keep consistency with deprecated ConfigEntityBase::link() method.
None
Add ConfigEntityBase::toLink() method to Drupal\Core\Config\Entity\ConfigEntityBase
None
While sourcepluginbase loads the source plugin configuration into the row to facilitate constants, SubProcess doesn't do this. We need access to all the statics that are setup in the source while inside of the SubProcess plugin.
$defaults = $this->configuration;
unset($defaults['plugin'], $defaults['key'], $defaults['process']),
$new_row = new Row($new_value + $defaults, array());
is my best guess.
Determine what breaks. Code, test, debate, review, commit, dance.
API page: https://api.drupal.org/api/drupal/core%21modules%21user%21user.api.php/f...
> \Drupal\Core\Session\AccountInterface $account: The user object on which the operation is being performed.
That's not true -- AccountInterface is not a 'user object'.
Also, the docs should mention that this hook is invoked both for user entities and the anonymous user session object.
Working on #2794347: Convert web tests to browser tests for field_ui module I discovered that some BTB tests there have a dependency on Drupal\field\Tests\EntityReference\EntityReferenceTestTrait.
It turns out that many BTB tests use this trait.
It provides a convenience method for creating an entity reference field, and does not perform any assertions.
Move the trait to core/modules/field/tests/src/Traits/, since it's used by both functional and kernel tests.
Deprecate Drupal\field\Tests\EntityReference\EntityReferenceTestTrait in favor of the new one.
After uninstall migration modules the tables created not removed and still exist and can not be reasonable to deploy without remove that tables.
Problem:
The 3 modules Migrate, Migrate_drupal, Migrate_drupal_ui didn't implement Hook_uninstall() to remove these tables or other data related to migration and have no use after complete migration.
Motivation:
List all tables prefixed with migrate_ in hook_install.
Implement hook_uninstall to remove all tables prefixed with migrate_ except those listed when install the same prefix.
Solution
The migrate core module must list all tables prefixed with migrate_ during installl.
The migrate module must remove all tables prefixed with migrate_ during uninstall.
Kindly reveal the wrong suppositions I made here and the best practice to achieve.
This issue only occurs with modules hooks - it has no impact in pure Drupal core.
In Drupal core, there is a single permission 'administer users' that controls whether a user can 'administer' the user account of another user. However the Drupal 8 Entity API makes it possible to refine the access, for example by means of hook_entity_access. This allows modules such as Administer Users by Role to create a "sub-admin" - a user without 'administer users' permissions that nevertheless has access to update some other users' account.
Unfortunately RegisterForm, ProfileForm and UserCancelForm are broken when used by the sub-admin. The problems arise from the fact that each form can be used in two ways: a normal user can update their own account or an admin can administer another user.
Tthe sub-admin sees the same interface as the admin, except missing fields such as role that require additionaly access.
The sub-admin sees a confusing mixture of the user and admin interfaces, for example:
Or if you prefer, can reproduce by writing custom code.
It is possible to fix all the problems using the extensive hooks provided by the user module. However it took 95 lines of code in Administer Users by Role. What's more, this code has detailed dependencies on the internal implementation in the user module, so may need to be updated for future Drupal versions.
You can test the workaround if you also install the sub-module administerusersbyrole_hack. You must disable this sub-module to see the bug.
Fortunately it seems possible to fix the forms with some fairly simple changes to the user module, without any negative impact on mainline use cases. This seems valuable and worthwhile because any contrib or custom code hooking into User access is likely to see the same problems.
Patch coming up.
The documentation for WriteSafeSessionHandlerInterface::isSessionWritable() describes the return value using the following phrase.
bool TRUE if the session the session is allowed to be written, FALSE otherwise.
the session is repeated twice.
For now, the CKEditorIntegrationTest for the DrupalImageCaption plugin doesn't exists.
I would suggest a new method for testDrupalImageCaptionDialog into the CKEditorIntegrationTest which will check the basic behaviours of DrupalImageCaption CKEditor Plugin.
Add a new testDrupalImageCaptionDialog method.
Should checks for:
filter_caption is enablefilter_caption is disableReview & Improve
None
None
None
Found in #2848952-14: Replace all calls to db_merge(), which is deprecated
Deprecated function db_merge() using to setup default db target but database service implementation don't
if (empty($options['target']) || $options['target'] == 'replica') {
$options['target'] = 'default';
}
other functions use different
if (empty($options['target'])) {
$options['target'] = 'default';
}
Move this hunk to \Drupal\Core\Database\Connection::merge()
- patch with test for replica & default target usage selection in merge
- agree & commit
no
\Drupal\Core\Database\Connection::merge() should work the same compatible way
no
If both modules big_pipe and prefetch_cache are turned on, then the prefetch caching would not work and an exception will be thrown, that the container is being serialized.
Prefetch cache caches the response object, which in the case of big pipe is BigPipeResponse. The class references some services, but doesn't include the DependencySerializationTrait. If we add the trait to the class, then it will be serialized properly, but now the response with the prefetch cache ID will be streamed. Thinking further it doesn't really make to use big pipe on prefetch cache requests, but there is no way for dynamically disabling big pipe on requests.
Make it possible through e.g. a query parameter to disable big pipe on requests.
I've configured image field so that alt text is required. It seems like this isn't validated in JSONAPI which allows me to both, save the field without alt text at all and to save the field with an empty alt text. I tried to find if there was test coverage for this but it seems like this wasn't tested at least specifically with an image field. I haven't tested if this happens also on 2.x branch.
Show validation error if alt text is missing when it has been marked as required.