Quantcast
Channel: Issues for Drupal core
Viewing all 294883 articles
Browse latest View live

Add support for Twig into Token::replace

$
0
0

Suggestion: add support for Twig into token module so that we can print tokens based on conditions like:

{# Directly access field in node entity #}
{% if node.myfield|isEmpty is not false %}[node:myfield:value]{% endif %}

{# or loop through token based on the field value #}
{% for key in node.foo|keys %}
Item: [node:foo:{{ key }}]
{% endfor %}

{# or work with token value(two syntaxes) #}
{% if token('node:foo') is not empty and token('node', 'bar') %}
[node:foo] [node:bar]
{% endif %}

In order for this to be possible some token-specific filters/function would have to be added - specifically "token" function.

The Twig would run before token replacement but Twig would have access to token replacements right away.

With this in place we could have conditional e-mails, notifications, error messages, logs...


Migrate D6 i18n translations of taxonomy vocabulary/terms

$
0
0

Problem/Motivation

In Drupal 6, you can use the I18n Taxonomy module to translate a taxonomy vocabulary and taxonomy terms. What happens when you do this is that:

  • You mark a particular vocabulary as having translatable terms. (In my site, I had one that was marked as translatable and one that wasn't).
  • If you go to the taxonomy page, like admin/content/taxonomy/5, you cannot see the translated taxonomy terms. But you can translate them by going to the central UI (locale) translation page (admin/build/translate), so the translated terms are stored in the same database tables as the UI translation strings. To translate, click on Search, and filter by Taxonomy, and if you have the i18n_taxonomy module enabled, you will see the translatable taxonomy terms there to translate.
  • After translating, if you view a translated node with one of the terms on it, and view it in Spanish, the term will show up in Spanish. Also, I made a block view that lists the tags (the translated vocabulary), and when viewing the site in Spanish, this block shows up in Spanish also.
  • In the D6 database:
    - term_data has the taxonomy term information
    - i18n_strings correlates term IDs to locale string IDs
    - locales_target has the actual translations in it
    Here's a query that illustrates the relationships:
    SELECT td.tid, td.name, lt.language, lt.translation FROM term_data td LEFT JOIN i18n_strings ist ON td.tid = ist.objectid LEFT JOIN locales_target lt ON ist.lid = lt.lid WHERE ist.type = 'term'

At this time, taxonomy terms translated in this way cannot be migrated into Drupal 8. If you have a Drupal 6 site with this setup, you get the English terms migrated in, and the English name for the vocabulary, but the translations are not migrated. The resulting site has the following in the database, after migrating from an actual D6 site with internationalized taxonomy terms (one vocabulary with English/Spanish terms, and one with just English terms):

  • Table migrate_message_d6_taxonomy_term_translation is there but empty, so Migrate thinks it did the translation migration with no messages.
  • Table migrate_map_d6_taxonomy_term_translation has 36 rows. 36 is the total number of taxonomy terms on the d6 site. 23 were from the translated vocabulary. The other 13 from the untranslated vocabulary.
  • Table taxonomy_term_field_data has 36 rows. Each one is an English taxonomy term. The langcode field is blank for all entries. There are no Spanish entries.

Note that #2784371: Migrate D6 i18n taxonomy term language (but not yet translations) migrated term language, and #2225781: Migrate D6 i18n taxonomy vocabularies migrated vocabulary language, but neither of them migrated translations. Also, once this is done, we can look at also making sure the translated nodes get the translated taxonomy terms, on #2859297: Migrate d6 translated nodes with translated taxonomy.

Proposed resolution

Migrate taxonomy vocabulary and term translations.

Remaining tasks

a) Make a patch with tests.
b) Test manually. jhodgdon's test instructions are in comment #12.

User interface changes

Taxonomy term translations will be migrated.

API changes

Probably not.

Data model changes

Probably not.

Detecting block type where are "This block is broken or missing"

$
0
0

Problem/Motivation

When you have a problem with your block you have just this message :" This block is broken or missing. You may be missing content or you might need to enable the original module."

But you can't know from what block arrived the problem

Proposed resolution

add in the message an element for identify from where this broken block come

User interface changes

-no

Data model changes

-no

insert() and other public methods with an $options param should refer to where to find details on this

$
0
0

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...

The $options param just says:

> array $options: (optional) An array of options on the query.

This is not very useful, and requires a developer to go digging in the source to figure this out.

The query() method explains more:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Database%...

The various methods such as insert(), update(), delete() need to do the same.

Though note that the link to the other method isn't properly being made:

> See the documentation for self::defaultOptions() for details

Missing help message when adding new action and Incorrect help message when editing action

$
0
0

Problem/Motivation

While trying to write the test case for #2917917: Change title for create action and edit action routes. I noticed the missing help message when adding a new action and incorrect help message when editing action. For example, Add and Edit screen of "Redirect to URL" action.

Add action screen:
Add action screen

Whilst there is a mistake in the help message. Help message refers to Description field while there is no Description field on that screen. It should refer to Label field.

Edit action screen:
Edit action screen

Proposed resolution

  1. I think it is a good idea to show same help message when adding new action because help message recommends editing the Label field.
  2. Update the help message to refer to the Label field instead of the Description field.

Remaining tasks

Write patch.

User interface changes

  1. Make correction in help message.
  2. Display help message on add action screen as well.

API changes

N/A

Data model changes

N/A

Fatal PHP error in Media (image) if one edits an image style after creating a media image

$
0
0

(Debian 8, Apache 2.4, Maria DB 5.5.60, PHP 5.6.33)

To reproduce the issue:

  • Install default Drupal 8 with composer
  • Enable media module
  • Create/upload a media image
  • Edit the name and Machine name of the default Thumbnail image style and save
  • Go the the /admin/content/media page or try to edit the created media image and you will get a 500 error or white screen

Also it throws an error if you try to add a new media image... it will let you pick an image, but will not finish the attachment of the image and you will be unable to save a new image media.

Another note is that the media image type is not even configured to use the thumbnail image style.

To fix I have tried to flush the thumbnail image style, run cron, clear all caches, and run update.php. So far nothing has helped, including trying to create a new image style and delete all the others, choosing the new style as the replacement style. On another website I even tried delete the media image type altogether and recreating (w/o changing styles again) a new media image type. The errors persist.

There are no errors in Drupal error logs. Apache's error logs show these errors:

PHP Fatal error: Call to a member function getCacheTags() on null in /www/test2/web/core/modules/image/src/Plugin/Field/FieldFormatter/ImageFormatter.php on line 199

PHP Fatal error: Call to a member function transformDimensions() on null in /www/test2/web/core/modules/image/image.module on line 298

Should one not be allowed to change the image style machine name (I'm assuming that's where the problem lies) once media is created? Thanks for any ideas or fixes.

Content moderation + migrate = unpublished nodes

$
0
0

Just found https://www.drupal.org/node/2839371, and although it is closed and works as designed, I had a small question,

we are importing nodes through migration and in the migration definition we specify the 'status' field for these nodes. We recently added content_moderation to these and now they are all imported 'unpublished' although the status gets a 1 from the migrated data. Any pointers how we can get these to become published? What property would we need to add to the migration config? Same for creating a node programmatically?

UPDATE: To import nodes as published in a site with the content_moderation module It is necessary to set a moderation state in the migration:

moderation_state: 
   plugin: default_value
   default_value: 'published'

"Authored on" string on multilanguage sites not translating; always renders English "ago" for "time ago" format

$
0
0

I came across a small glitch when using views on a multilanguage site. When using the "Authored On" field in a view, views will not use a translated version of the whole string but only of the time itself. For example:

  • Last updated: 2 hours 34 minutes ago
  • Letztes update: 2 Stunden 34 Minuten ago

As for the second line (which is in German), the "ago" should switch to a place in front of the string and be translated to "vor".

I checked the string translations but could not find the correct one; I'd be more than happy to fix this if someone could just point me to the right location. I also found other Drupal 8 sites while doing my research about this which are suffering from the same problem.


Add ability to disable AJAX for Views exposed form submit

$
0
0

Request: Provide configuration to disable AJAX for Views exposed form submission.

Current Code: If the view is enabled to "use ajax", then form submission and pagers are setup to use AJAX.

Use Case: Non-AJAX form submission with an AJAX pager. This case is useful when there are non-view related content on the page that needs to change based on the views results. Example: Facet blocks for Search API views.

Install profile in settings.php and mismatch check makes re-installs of Drupal hard

$
0
0

Problem/Motivation

#2156401: Write install_profile value to configuration and only to settings.php if it is writeable changed from always writing the install profile to configuration, and only to settings.php if settings.php is writable.

Change record is here: https://www.drupal.org/node/2538996

However this leaves a relatively annoying issue when re-installing Drupal.

Steps to reproduce:

1. Install minimal profile
2. Drop the database, try to reinstall with Standard (doesn't matter if this is via drush or the UI)
3. You'll see an error message about the install profile in settings.php not matching the chosen profile.

Proposed resolution

Completely stop writing the install profile to settings.php regardless of whether it's writable or not.

Remaining tasks

User interface changes

API changes

We'e already deprecated getting the install profile from settings.php and accepted it won't always be available there for new sites where settings.php is read-only. Given this change will also only affect new sites, it should not in practice break bc that anyone is relying on at this point.

Data model changes

Redirect loop on clean install with Drupal 8.0-alpha4 on CPanel

$
0
0

The subject tells the tale: on a clean install of Drupal 8, I get a redirect loop that eventually times out. I would mark this as critical since it makes it impossible to install Drupal, but there seems to be some strange combination of server + Drupal 8 that may be quite rare. Still this is a default account as set up automatically by CPanel, so I wouldn't think it would be *that* rare.

I know it has to be an odd combo, because this server previously ran D8 just fine and it currently runs D7 just fine.

It's a CentOS VPS with CPanel. I completely wiped the account and started over with a completely clean account. Once again, D8 had an infinite redirect loop, while Drupal 7 installed just fine.

What works. What doesn't

The symptoms described below are the same using either a git clone from today or the Drupal 8.0-alpha4 release.

  • This server was successfully running a D8 site based on a git pull in September or so.
  • It serves up a phpinfo() output file and /core/INSTALL.txt just fine. It only hangs on /core/install.php
  • It successfully redirects from http://example.com/ to http://example.com/core/install.php. Then it requests that file many times until it dies (see HTTP Headers output).
  • Drupal 7 installs as expected, no problem.
  • The site that was running on this server is still running fine on my Acquia Dev Desktop under Apache 2.2.22 PHP 5.3.18 and 5.4.8 and MySQL 5.1. I updated it with a git pull from Oct 17 and it is running.

So in short, everything works on this server except D8. The D8 works for me elsewhere, just not on this server.

Server

  1. Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4 mod_fcgid/2.3.6
  2. PHP Version 5.4.20
  3. MySQL 5.0.96
  4. CPanel running CentOS
  5. Server API CGI/FastCGI

Error Messages

To make this more likely to come up in search for users with a similar issue, the error message depends on the browser:

  • Chrome: This webpage has a redirect loop
  • Firefox: The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

Sometimes it runs out of memory and crashes first, so it throws an error like:

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 3054627593 bytes) in /home/yourfit/public_html/core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/ParameterBag/ParameterBag.php on line 260

HTTP Headers output

See attached

Incorrect behaviour for block page visibility

$
0
0

Problem/Motivation

When leaving the "listed pages" text area empty in "Pages" block visibility, the options "Show for the listed pages" and "Hide for the listed pages" do the exact opposite of what they claim, they work as though there was an entry * in the list, i.e.:

  • Show for the listed pages will result in the block showing on all pages when the list is empty
  • Hide for the listed pages will result in the block showing nowhere when the list is empty

For an empty list, "Show on the listed pages" should not show the block anywhere. And, "Hide on the listed pages", should have the block show up on every page, when the list is empty.

Proposed resolution

This issue could be solved in several ways, we should probably just discuss what is the best way forward. The possible options:

  • Make the options just work as advertised, i.e. an empty list will cause the exact opposite of entering a single * for both options
  • Make it impossible to empty the list, defaulting it to "*" when left empty (this should probably be reported in a user message).
  • Don't change anything except add a little explanation to the UI stating that leaving the list empty is equivalent to "all".
  • Uncheck "Show for the listed pages" if pages textarea is empty

One consideration is that the default currently causes the block to show everywhere, which in itself is probably a good default. It's just that it is being achieved by combining "Show on the listed pages" with an empty list, which at least caused me to select "Hide on the listed pages", expecting that to result in the block showing everywhere.

Remaining tasks

  1. Decide on resolution
  2. Implement resolution

User interface changes

Undetermined

API changes

None.

Allow run-tests.sh to generate coverage reports

$
0
0

Problem/Motivation

The testbot is built with phpdbg. This allows us to generate coverage reports from PHPUnit with minimal performance penalty. This can be seen in the testbot's native test runs: https://dispatcher.drupalci.org/job/DrupalCI_CI_Ci_ci/403/

The problem: run-tests.sh can't natively handle coverage, and we don't want to run tests twice just for a coverage report.

We also have a situation where if we ran the phpunit tool to generate a full coverage report, it would take a whole day, or maybe longer. So the advantage of run-tests.sh in this regard is concurrency.

Proposed resolution

run-tests.sh invokes simpletest_script_run_one_test() which can use phpdbg instead of php if we want it to generate a coverage report.

We then have PHPUnit generate coverage using --coverage-php (named .cov files by convention).

At the end of the test run, we use phpcov to aggregate the .cov files into a Clover XML file.

Remaining tasks

User interface changes

API changes

Data model changes

Html::serialize() escapes \r to 

$
0
0
use \Drupal\Component\Utility\Html;
$html_dom = Html::load("<b>text</b>\r\n");
echo Html::serialize($html_dom);

The above code returns <b>text</b>&#13;

Error: Call to undefined function _datetime_type_field_views_data()

$
0
0

I have an sometime error with datetime_range core module.

After clear cache it's work normally

Error: Call to undefined function _datetime_type_field_views_data() in /project/web/core/modules/datetime_range/datetime_range.views.inc on line 14 #0 [internal function]: datetime_range_field_views_data(Object(Drupal\\field\\Entity\\FieldStorageConfig))\n#1 /project/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('datetime_range_...', Array)\n#2 /project/web/core/modules/views/views.views.inc(183): Drupal\\Core\\Extension\\ModuleHandler->invoke('datetime_range', 'field_views_dat...', Array)\n#3 [internal function]: views_views_data()\n#4 /project/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('views_views_dat...', Array)\n#5 /project/web/core/modules/views/src/ViewsData.php(245): Drupal\\Core\\Extension\\ModuleHandler->invoke('views', 'views_data')\n#6 /project/web/core/modules/views/src/ViewsData.php(162): Drupal\\views\\ViewsData->getData()\n#7 /project/web/core/modules/views/src/Plugin/ViewsHandlerManager.php(85): Drupal\\views\\ViewsData->get('node')\n#8 /project/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(889): Drupal\\views\\Plugin\\ViewsHandlerManager->getHandler(Array, NULL)\n#9 /project/web/core/modules/views/src/ViewExecutable.php(1040): Drupal\\views\\Plugin\\views\\display\\DisplayPluginBase->getHandlers('field')\n#10 /project/web/core/modules/views/src/ViewExecutable.php(898): Drupal\\views\\ViewExecutable->_initHandler('field', Array)\n#11 /project/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2268): Drupal\\views\\ViewExecutable->initHandlers()\n#12 /project/web/core/modules/views/src/ViewExecutable.php(1689): Drupal\\views\\Plugin\\views\\display\\DisplayPluginBase->preExecute()\n#13 /project/web/core/modules/views/src/ViewExecutable.php(1624): Drupal\\views\\ViewExecutable->preExecute(Array)\n#14 /project/web/core/modules/views/src/Element/View.php(77): Drupal\\views\\ViewExecutable->executeDisplay('page_1', Array)\n#15 [internal function]: Drupal\\views\\Element\\View::preRenderViewElement(Array)\n#16 /project/web/core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func(Array, Array)\n#17 /project/web/core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\\Core\\Render\\Renderer->doRender(Array, false)\n#18 /project/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\\Core\\Render\\Renderer->render(Array, false)\n#19 /project/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->Drupal\\Core\\Render\\MainContent\\{closure}()\n#20 /project/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\\Core\\Render\\Renderer->executeInRenderContext(Object(Drupal\\Core\\Render\\RenderContext), Object(Closure))\n#21 /project/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->prepare(Array, Object(Symfony\\Component\\HttpFoundation\\Request), Object(Drupal\\Core\\Routing\\CurrentRouteMatch))\n#22 /project/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\\Core\\Render\\MainContent\\HtmlRenderer->renderResponse(Array, Object(Symfony\\Component\\HttpFoundation\\Request), Object(Drupal\\Core\\Routing\\CurrentRouteMatch))\n#23 [internal function]: Drupal\\Core\\EventSubscriber\\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#24 /project/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher))\n#25 /project/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\\Component\\EventDispatcher\\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\\Component\\HttpKernel\\Event\\GetResponseForControllerResultEvent))\n#26 /project/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\\Component\\HttpKernel\\HttpKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request), 1)\n#27 /project/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\\Component\\HttpKernel\\HttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#28 /project/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\\Core\\StackMiddleware\\Session->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#29 /project/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\\Core\\StackMiddleware\\KernelPreHandle->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#30 /project/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\\page_cache\\StackMiddleware\\PageCache->pass(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#31 /project/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\\page_cache\\StackMiddleware\\PageCache->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#32 /project/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\\Core\\StackMiddleware\\ReverseProxyMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#33 /project/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\\Core\\StackMiddleware\\NegotiationMiddleware->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#34 /project/web/core/lib/Drupal/Core/DrupalKernel.php(664): Stack\\StackedHttpKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request), 1, true)\n#35 /project/web/index.php(19): Drupal\\Core\\DrupalKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#36 {main}


Make serializer customizable for Cache\DatabaseBackend

$
0
0

Problem/Motivation

The Drupal\Core\KeyValueStore\DatabaseStorage uses a configurable serializer to store PHP objects. This serializer is injected as a service in core. The pre-configured serializer used there Drupal\Component\Serialization\PhpSerialize:

  keyvalue.database:
    class: Drupal\Core\KeyValueStore\KeyValueDatabaseFactory
    arguments: ['@serialization.phpserialize', '@database']
  serialization.phpserialize:
    class: Drupal\Component\Serialization\PhpSerialize

This architecture allows contrib modules like https://www.drupal.org/project/igbinary to swap the serializer. For example igbinary shrinks the size of larger serialized PHP objects to one third without losing any performance. (In some cases the performance is increased as well.)

Having this kind of memory saving would be a huge benefit for all kind of drupal caches that store serialized PHP objects, especially if there using in memory solutions like memcache. Systems like redis or even the database will benefit from igbinary as well.

Unfortunately the Drupal\Core\Cache\DatabaseBackend and the Drupal\Core\Cache\MemoryBackend use a hard-coded PHP serialization. Therefore the could not be easily improved by modules like https://www.drupal.org/project/igbinary

Proposed resolution

Follow the pattern of Drupal\Core\KeyValueStore\DatabaseStorage and Drupal\Core\KeyValueStore\DatabaseStorageExpirable and inject the serialize as a service to the Drupal\Core\Cache\DatabaseBackend.

The default configuration in core should then "remain" as it is and inject Drupal\Component\Serialization\PhpSerialize.

Even if this improvement makes sense for the Drupal\Core\Cache\MemoryBackend as well, @catch decided to not modify it in core. This backend is heavily used in the tests which will be more complicated afterwards. Therefore the igbinary contrib module will provide it's own backend as drop-in replacement.

As proposed by @berdir we introduce a "new" service serialization.objectaware.default that is in core just an alias for serialization.phpserialize. The redis module will leverage this one as well as soon as this patch gets committed. This new default service eases the task for the modules like igbinary to switch (most of) the serilaizers system wide.

Remaining tasks

Review the existing patch.

User interface changes

None.

API changes

Similar to Drupal\Core\KeyValueStore\KeyValueDatabaseFactory and Drupal\Core\KeyValueStore\DatabaseStorage the constructor of Drupal\Core\Cache\DatabaseBackend an its factory need to be prepared for dependency injection.
In addition we define a new interface Drupal\Component\Serialization\ObjectAwareSerializationInterface that just extends Drupal\Component\Serialization\SerializationInterface to clearly indicate that implementing Serializers are suitable for PHP Object serialization.

Old:

DatabaseBackendFactory::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider);
DatabaseBackend::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider, $bin);

New:

interface ObjectAwareSerializationInterface extends SerializationInterface {}

DatabaseBackendFactory::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider, ObjectSerializationInterface $serializer = NULL);
DatabaseBackend::__construct(Connection $connection, CacheTagsChecksumInterface $checksum_provider, $bin, ObjectSerializationInterface $serializer = NULL);

These API changes don't break BC!

Data model changes

None.

Image media source uses FileSystem class instead of FileSystemInterface for type hinting

$
0
0

Problem/Motivation

core/modules/media/src/Plugin/media/Source/Image.php is using Drupal\Core\File\FileSystem class instead of Drupal\Core\File\FileSystemInterface for type hinting in its constructor.
This causes problem when someone wants to use custom FileSystem class instead of default one.
It works fine if we use FileSystemInterface instead of FileSystem.

Improve usability of Views bulk action form in Seven theme

$
0
0

Problem/Motivation

The styling for the Views bulk action form is limited and can lead to confusion when presented along side other form elements. For example, on the administration content listing page (/admin/content) the bulk action form is presented beneath the exposed filter form and confusion can exist between the fields and apply buttons for the two forms.

Before:

Current bulk action form on admin content page

Proposed resolution

Add a wrapper mechanism and some simple block styles to the bulk action form wherever it appears in the Seven theme (both for views bulk operations and hardcoded bulk operations like the comment list).

Maybe in the future

An enhanced version is possible that 'joins' the Views table header visually with the bulk action form, adding an additional pointer arrow to the 'select' checkbox column. This approach would not work when the View doesn't use a table display, so we discarded this for now.

Proposed bulk action form on admin content page - enhanced version

Remaining tasks

Reviews.

User interface changes

Change of Views bulk action form styling background and border, see proposed resolution.

API changes

No changes. Adding #bulk_operations element.

Data model changes

None

Move Relationships above Contextual Filters in Views Advanced Settings

$
0
0

In Views UI Advanced settings, Contextual Filters are placed above Relationships. The problem with this order is that some contextual filters (arguments) only show up if the users chooses a relationship first.

Views Advanced Settings current sequence

People tend to work top down, so imho some misconceptions about contextual filters and relationships could easily be avoided by changing the order of this items and listing relationships above contextual filters.

In others words, contextual filters may depend on relationships, so the latter ones should be listed first.

Random Failure in Drupal\Tests\Core\Command\QuickStartTest

$
0
0
Viewing all 294883 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>