In Drupal 7, the CKEditor Link plugin enabled you to choose the type of link - anchor link, email link, or URL.
In D8, the link plugin only supports URLs.
This makes it harder for authors to add inline mailto links, as they have to manually build the link by typing in HTML. Could we re-introduce the 'link type' option D7, so that if "Email link" is selected we show fields for subject & body?
Hello.
Currently, if Drupal uses cacheing, then opening a suburl will only increment the content's view counter, if JavaScript is available on the client side. If for example company policy forbids this, to prevent doubling the HTTP queries, then a server side solution is needed.
Is an option for this is available in the Drupal Core cacheing system? If not, if i send in a patch for this option, will it be merged by any chance?
Thanks in advance.
I encounter an error when I want to add a new language in the Drupal site using /admin/config/regional/language/add path.
The error is:
'Error: Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights()'
Even if the error is received the language is created when I go on the language list.
I am using Drupal 8.5.1 version.
There is a new symfony release.
Update symfony packages to 3.4.33
Patch.
Review.
Commit.
None
None.
None.
Symfony packages have been updated to 3.4.33
As shown in #2699895: Allow configurable date attributes to collect, the Drupal 7 date module allowed the site builder to configure which granularity to collect:
For example, on my personal site, I have a projectNodeType which has a "time range"date field that only cares about year + month granularity. Example: https://wimleers.com/work/project/cdn-far-future-expiration-drupal-7.
When migrating this to Drupal 8, \Drupal\datetime\Plugin\migrate\field\DateField::defineValueProcessPipeline() chokes on this
Make \Drupal\datetime\Plugin\migrate\field\DateField::defineValueProcessPipeline() more robust.
TBD
N/A
N/A
N/A
TBD
#2851635: DefaultSingleLazyPluginCollection retains stale instance IDs shows that base plugin classes should all merge default configuration in the same way. We should supply a trait to make it easy to correctly implement \Drupal\Component\Plugin\ConfigurableInterface.
Add new trait and use it where appropriate in core.
None
New trait
None
Right now, MediaLibraryState is using the service locator pattern to do some important stuff, like in the getHash() method. We probably should not be doing this kind of thing -- instead, we should have a factory service to create MediaLibraryState objects with proper dependency injection.
Add a factory service which is responsible for creating MediaLibraryState instances with their dependencies (such as the private key service) properly injected.
That.
None.
Yes, probably.
Definitely none.
TBD, but probably none. This is internal refactoring.
Replies to forum topics break words unnecessarily on the right-most side of the comments field.
This issue was a regression introduced in #1085472: Long strings within comments break Bartik's page layout..
Enable forum module or create a content type with the ability to leave comments
Post a forum topic or create a node (example: basic page)
Post a reply or comment (with some text, a long URL and the longest word in the dictionary - Pneumonoultramicroscopicsilicovolcanoconiosis).
Adjust your browser's window width
See words being broken, their first part at the end of a line, their second part at the beginning of the next line
see attached screenshot
Also, note the lack of hyphens to notify you that the word broke
The issue has been observed on Chrome 47.0, Firefox 44.0.2 and IE11.
Use css break-word instead of break-all
Add support for hyphens
Break hyperlinks in comments in all cases
Before the change:
After the change:
I created book migration configuration based on docroot/core/modules/book/migrations/d7_book.yml to migrate book data from Drupal 7 to Drupal 8. Running drush migrate-import works, but when I add the --update flag, all items fail with errors.
I was expecting that the migration would update like node and other migration plugins, error free.
When running the book migration with the --update flag, all items fail and the following errors occur for each item:
[error] Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2826' for key 'PRIMARY': INSERT INTO {book} (nid, bid, pid, weight, depth, p1, p2, p3, p4, p5, p6, p7, p8, p9) 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); Array
(
[:db_insert_placeholder_0] => 2826
[:db_insert_placeholder_1] => 2816
[:db_insert_placeholder_2] => 2816
[:db_insert_placeholder_3] => 5
[:db_insert_placeholder_4] => 2
[:db_insert_placeholder_5] => 2816
[:db_insert_placeholder_6] => 2826
[:db_insert_placeholder_7] => 0
[:db_insert_placeholder_8] => 0
[:db_insert_placeholder_9] => 0
[:db_insert_placeholder_10] => 0
[:db_insert_placeholder_11] => 0
[:db_insert_placeholder_12] => 0
[:db_insert_placeholder_13] => 0
)
in Drupal\Core\Database\Connection->handleQueryException() (line 683 of /app/docroot/core/lib/Drupal/Core/Database/Connection.php).
[error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2826' for key 'PRIMARY': INSERT INTO {book} (nid, bid, pid, weight, depth, p1, p2, p3, p4, p5, p6, p7, p8, p9) 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); Array
(
[:db_insert_placeholder_0] => 2826
[:db_insert_placeholder_1] => 2816
[:db_insert_placeholder_2] => 2816
[:db_insert_placeholder_3] => 5
[:db_insert_placeholder_4] => 2
[:db_insert_placeholder_5] => 2816
[:db_insert_placeholder_6] => 2826
[:db_insert_placeholder_7] => 0
[:db_insert_placeholder_8] => 0
[:db_insert_placeholder_9] => 0
[:db_insert_placeholder_10] => 0
[:db_insert_placeholder_11] => 0
[:db_insert_placeholder_12] => 0
[:db_insert_placeholder_13] => 0
)
(/app/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:783) The logo and site-name links in the the SystemBrandingBlock have a useless title attribute
This is the code in the block--system-branding-block.html.twig templates (approximately, some have classes etc).
{% if site_logo %}
<a href="{{ path('<front>') }}" title="{{ 'Home'|t }}" rel="home">
<img src="{{ site_logo }}" alt="{{ 'Home'|t }}" />
</a>
{% endif %}
That duplication of title and link content (alt tag in this case) is recommended against.
Depending on screen reader configuration etc, it may cause duplication in playback, and in any case provides no additional value.
Remove the title attribute from links in the System Branding Block templates.
Include the Bartik, Classy and Stable themes in this update, as this is a low-risk change/no class changes. Include the change to the Umami theme/demo as no risk there and the demo should be as accessible as possible.
Check with a front-end framework manager about updating Stable and Classy themes.
Remove the title attribute from these templates.
Removes the title attribute from links in the System Branding Block templates.
None
None
UrlHelper::parse does not support external URLs with more than one question mark. At the moment some parts of the URL gets stripped of in case there are more than one question mark which is not properly encoded. Thus we do not consider the URL as invalid, so we must return the fully constructed and properly encoded URL when this is the case.
Example of problematic URL :http://ville.montreal.qc.ca/portal/page?_pageid=3619,4034073&_dad=portal&_schema=PORTAL¶ms_recherche=http://ville.montreal.qc.ca/sel/sypre-consultation/recherchereglement?params=type_regl=999**critere=pesticides**source=**type_recherche=0**total=0**crement=10**start_pos=1**acces=0**langue=fr**instances=901**expression=pesticides**etendue=titre**statut=1**no_reglement=04-041**no_regl_cond=**applic_territ=0**bro_orderdate=2016-02-01**bro_endorderdate=2016-02-01**utilisateur=&has_been_there=1
When passed through UrlHelper::parse it returns :http://ville.montreal.qc.ca/portal/page?_pageid=3619,4034073&_dad=portal&_schema=PORTAL¶ms_recherche=http://ville.montreal.qc.ca/sel/sypre-consultation/recherchereglement
The fix is very simple, we just need to explode the URI considering the first question mark.
Patch attached.
template_preprocess_pager() passes a $quantity variable into the ceil() function without making sure that it is an integer (or a number for that matter). As a result, PHP 7.1 (and greater) complains:
A non-numeric value encountered
Casting the $quantity variable into an (int) should get rid of the warning.
Provide a patch.
N.B.: Attached is a dummy patch that demonstrates the problem,
it ran as part of this comment #2902430-35: [D7] PHP 7.1 warning: A non-numeric value encountered in theme_pager()
results were reported here https://www.drupal.org/pift-ci-job/1473318
Reproduce the bug
Set up a site with for example simplytest.me and enable the layout builder module.
Enable layout builder for basic pages, create a basic page and add a title to the page.
Expected behavior
When viewing the created node, I expected to not get a wrapping div around the page title with data attributes from layout builder.
What happened instead?
The page title gets wrapped inside a div with a data attribute from layout builder:
<div data-layout-content-preview-placeholder-label=""Title" field"><h1>Page title</h1></div>
When a relationship field has a "virtual" target, such as when a taxonomy term's parent is the non-existent "root" term, JSON:API has to perform some special magic to ensure that it's not actually a data integrity issue.
Part of that process is to get a list of target resource types for the field in question. JSON:API currently fails to account for the fact that the field name might be aliased.
Ensure that JSON:API gets the internal field name before trying to get a list of relatable resource types.
Nope.
Nope.
Nope.
N/a
Migration plugins throughout core and contrib keep having to do this sort of thing:
$delimiter = isset($this->configuration['delimiter']) ? $this->configuration['delimiter'] : '';
Implementing https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Plug... means that plugins can define default values for any configuration in defaultConfiguration().
The result is:
- better DX as you don't have to keep checking array values in $this->configuration are defined
- better DX as the default value for something in $this->configuration is in one place only
- better DX as there's a place where all the configuration options for the class are listed (well the class docs should have that too... but it nudges modules that are lax on docs towards listing them)
This can be done in SourcePluginBase, ProcessPluginBase, & DestinationBase.
To facilitate this, create an @internal ConfigurablePluginTrait in the migrate module to use with migration base plugins. There is discussion to do this in the core plugin system in #2852463: Create a trait to implement \Drupal\Component\Plugin\ConfigurableInterface, however for the migration plugins we want to prevent use of the calculateDependencies method from the interface, as these plugins are not configurations and do not use dependencies. Depending on the outcome of that issue and #2946122: Deprecate ConfigurablePluginInterface and replace with an interface that doesn't extend DependentPluginInterface there may be a future core plugin library solution to address this, and refactoring the migration plugins around a module trait now will make that process much easier, and provide immediate benefits in cleaning up the plugin code. Making the trait @internal will make sure we can refactor around any potential plugin library solution in the future.
Create an @internal ConfigurablePluginTrait use with migration base plugins.
Implement ConfigurablePluginInterface in the migration base classes and use the trait. Remove the interface from any core classes that extend these base classes.
Remove unused calculateDependencies() methods from core migration plugins as these plugins are not config entities.
Commit it!
As a follow up to this issue, refactor plugins to set default configurations and remove unnecessary isset() calls. @see #2995393: Refactor migrations plugins that now implement ConfigurablePluginInterface
None.
None.
None.
When the referenced item is deleted targted_id is still present in the reference field, so existing EntityReferenceItem::isEmpty() will return FALSE
This issue causes other functionality to fail. E.g. jsonapi_extras (check child issues).
Always check against an entity existense.
Now that #2880152: Convert custom menu links to be revisionable is in, changes to menu links in non-live workspaces are not showing up. Making changes, and publishing changes from non-live to live works well. But it's not possible to preview the changes on the site's frontend.
This is probably due to cache issues where rendered menus needs to be cached per workspace.
Cache menus per workspace.
None.
After #1596472: Replace hard coded static cache of entities with cache backends core with have \Drupal\Core\Cache\MemoryCache\MemoryCache and \Drupal\Core\Cache\MemoryBackend.
MemoryBackend is supposed to be used only for testing, whereas MemoryCache will be used for all entity storage.
Rename MemoryBackend to something else, such as MemoryTestingBackend or similar.
MemoryCache currently extends from MemoryBackend, but when we do the rename we may want to make the new class inherit from MemoryCache instead. Except we probably don't want to do that because MemoryBackend wouldn't confirm to MemoryCacheInterface - so perhaps add a trait instead or just duplicate the code.
In the patch that marks the Workspaces module as stable, we found that the workspace entity type is missing some REST and JSON:API test coverage.
Add the missing test coverage.
Review.
Nope.
Nope.
Nope.
TBD.
When creating a revision of a published node in a different language, the content type doesn't get set. I believe this affects the permissions too as anyone without the "Bypass content access control" cannot view that revision of the node in the Moderated Content view.
Steps to reproduce:
1. Install Content Moderation and Content Translation modules on a clean installation.
2. Add a language.
3. Edit the default Editorial workflow and apply the workflow to the Basic page content type.
4. Edit the Basic page content to enable revisions "Create new revision" and enable translation.
5. Create new basic page and set to be published.
6. Create a translation of the page in the other language and set to be draft.
7. Go to the Moderated content view (/admin/content/moderated) and notice the content type doesn't display for the draft. The whole draft won't show in the view for other users without the "Bypass content access control" permission.
I'd expect the content type to show and the users with the "View any unpublished content" to be able to view it.