I found the report at admin/content/moderated to be unusable without any filters on it, so I configured a view to override that page.
↧
View for Moderated Content Admin Page
↧
invalid conf file warnings when skip_permissions_hardening is on
Problem/Motivation
At the moment when $settings['skip_permissions_hardening'] = TRUE, the system module's system_requirements unconditionally issues a warning about the site's config files' permissions without actually checking them:
if (file_exists($full_path) && (Settings::get('skip_permissions_hardening') || !drupal_verify_install_file($full_path, FILE_EXIST | FILE_READABLE | FILE_NOT_WRITABLE))) {
$conf_errors[] = t("The file %file is not protected from modifications and poses a security risk. You must change the file's permissions to be non-writable.", ['%file' => $full_path]);
}
This is quite confusing and misleading (see related issues).
Proposed resolution
Drupal should either skip the checks and not issue any warnings about the state of specific conf files, or perform the checks but only issue any valid warnings (as opposed to errors).
A simple warning to remind developers not to carry this configuration over into production would seem sufficient.
Remaining tasks
* Decide whether to skip checks, or perform them and issue only valid warnings.
* Patch the existing code accordingly.
* Update tests as appropriate.
User interface changes
* Removal of invalid warnings when config file permissions are not actually incorrect.
API changes
* None.
Data model changes
* None.
↧
↧
Update symfony/* and twig/twig
Problem/Motivation
Follow-up to #2940367: Update Symfony components to 3.4.4
Proposed resolution
Update Symfony components to 3.4.9
Update Twig to v1.35.3
Remaining tasks
Review
Commit
User interface changes
N/A
API changes
N/A
Data model changes
N/A
↧
Caches not working as expected
I am not sure if this is a bug or "as designed".
If you do a fresh site install with standard profile, add the Who's online block to the content region, and then create/save a page, then go in as anon user and hit the page (should be /node/1) then look in page cache and dynamic page cache data fields in database, the entire Who's online block is cached with page.
I also tried adding a hook in my_module.module that makes every block have a timeout of 0:
function my_module_block_build_alter(array &$build, \Drupal\Core\Block\BlockPluginInterface $block) {
$build['#cache']['max-age'] = 0;
}
But the blocks are not placeholdered, but rather are included in the page cache and dynamic page cache data fields in the database.
Perhaps I am missing something obvious.
Thanks for you help,
captaindav
↧
Fix "Drupal\system\Tests\Menu\AssertBreadcrumbTrait is deprecated in Drupal 8.4.0 and will be removed before Drupal 9.0.0. Instead, use \Drupal\Tests\system\Functional\Menu\AssertBreadcrumbTrait"
Problem/Motivation
Drupal\system\Tests\Menu\AssertBreadcrumbTrait is deprecated in Drupal 8.4.0 and will be removed before Drupal 9.0.0.
Proposed resolution
Instead, use \Drupal\Tests\system\Functional\Menu\AssertBreadcrumbTrait.
Remaining tasks
User interface changes
API changes
Data model changes
Original report by [username]
↧
↧
Stable theme does not respect "visually hidden" field label display option
Site builders can set field labels to be hidden (not output at all) or visually hidden (text is available to screen readers) via admin/structure/types/manage/<content_type>/display. The Stable theme does not add the proper class to the field label to achieve the "visually hidden" effect.
Steps to repro:
- Standard install profile with some devel generated content
- Navigate to
admin/structure/types/manage/article/display - For the "Image" field, change the "Label" setting to "Visually hidden"
- Create a dummy theme with the following in
dummy.info.ymlname: Dummy Testing Theme type: theme core: 8.x base theme: stable - Enable and set as default the new Dummy theme
- Navigate to an article node
↧
NegotiationMiddleware calls $request->setRequestFormat('html') when there is no _format request parameter, but shouldn't
Problem/Motivation
This core bug blocks this JSON API contrib module issue: #2831137: Remove the need for ?_format=api_json: assume the use of the 'api_json' format for routes managed by JSON API.
Observation 1
Currently, the fallback for \Drupal\Core\StackMiddleware\NegotiationMiddleware::getContentType() (i.e. if no ?_format= querystring is specified) is this:
// Do HTML last so that it always wins.
return 'html';
And \Drupal\Core\StackMiddleware\NegotiationMiddleware::handle() does this:
// Determine the request format using the negotiator.
if ($requested_format = $this->getContentType($request)) {
$request->setRequestFormat($requested_format);
}
The end result is that $requested_format is never empty. It always is set to 'html'.
Observation 2
Now let's look at \Symfony\Component\HttpFoundation\Request::getRequestFormat(), which is what the router (and controllers) use to determine the request format
/**
* Gets the request format.
*
* Here is the process to determine the format:
*
* * format defined by the user (with setRequestFormat())
* * _format request parameter
* * $default
*
* @param string $default The default format
*
* @return string The request format
*/
public function getRequestFormat($default = 'html')
{
if (null === $this->format) {
$this->format = $this->get('_format', $default);
}
return $this->format;
}
Result
The result is that Request::getRequestFormat()'s $default parameter is broken in Drupal, because NegotiationMiddlewarealways sets it to 'html'. Even when there is no _format request parameter.
In other words: NegotiationMiddleware breaks the Symfony Request API.
Proposed resolution
Only let NegotiationMiddleware call Request::setFormat() when there actually is a _format request parameter.
Remaining tasks
TBD
User interface changes
None.
API changes
None.
Data model changes
None.
↧
Convert \Drupal\Tests\taxonomy\Functional\Views\TaxonomyDefaultArgumentTest to a kernel test
Problem/Motivation
Most of \Drupal\Tests\taxonomy\Functional\Views\TaxonomyDefaultArgumentTest can actually be a kernel test and as such be executed faster.
Proposed resolution
Convert all beside \Drupal\Tests\taxonomy\Functional\Views\TaxonomyDefaultArgumentTest::testTermTitleEscaping to a kernel test
Remaining tasks
User interface changes
API changes
Data model changes
↧
Deletion of View Block used by Layout Builder
Deletion of view used by layout builder breaks page with custom layout built by layout builder.
Problem/Motivation
I did following.
- create some simple view block
- used it for layouting of single page (so configuration will be saved in field)
- delete view block
- open previously layouted page
And following exception is thrown:
TypeError: Argument 1 passed to Drupal\views\ViewExecutableFactory::get() must implement interface Drupal\views\ViewEntityInterface, null given, called in /var/www/html/core/modules/views/src/Plugin/Block/ViewsBlockBase.php on line 69 in Drupal\views\ViewExecutableFactory->get() (line 70 of core/modules/views/src/ViewExecutableFactory.php).
Drupal\views\ViewExecutableFactory->get(NULL) (Line: 69)
Drupal\views\Plugin\Block\ViewsBlockBase->__construct(Array, 'views_block:test-block_1', Array, Object, Object, Object) (Line: 84)
Proposed resolution
Maybe this is a bit conceptual problem with saving layout builder information as a serialized blob.
This is one case where the problem occurs, another possible case is when some module provides block and wants to update its configuration. How I see it, update hook should go over all layout fields -> load config -> check if there is a config for that particular block ->update it -> serialize again.
↧
↧
@var tag must not end with a full stop
Part of #2909370: [PP-3] Fix 'Drupal.Commenting.VariableComment.IncorrectVarType' coding standard
Remove full stops (semicolons, periods) from @var tags.
↧
Move the comment hostname default value to a default value callback
Problem/Motivation
Split from #2687977: Comment::preSave() unconditionally sets hostname to client host. A new comment entity gets a default value for an uninitialised hostname from the current request. But this is hardcoded in Comment::preSave().
Proposed resolution
Remove the hard-coding by creating an default value callback that sets the hostname from the current request.
Provide:
- Tests
- Update path.
- Update path tests.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
The Comment hostname base field definition changes.
↧
TestSiteApplicationTest requires a database despite being a unit test
Problem/Motivation
Two problems:
1) Unit test requires a database
Running TestSiteApplicationTest in isolation reveals that it errors out.
That's because it uses the SIMPLETEST_DB environmental variable, which is intended for use by KernelTestBase tests.
$ ./vendor/bin/phpunit -c core/ --testsuite unit --filter TestSiteApplicationTest
PHPUnit 6.5.8 by Sebastian Bergmann and contributors.
Testing
EEESS. 6 / 6 (100%)
Time: 17.01 seconds, Memory: 136.00MB
There were 3 errors:
1) Drupal\Tests\Scripts\TestSiteApplicationTest::testInstallWithNonExistingFile
InvalidArgumentException: Minimum requirement: driver://host/database
/Users/paulmitchum/projects/drupal8/core/lib/Drupal/Core/Database/Database.php:460
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:267
/Users/paulmitchum/projects/drupal8/core/tests/Drupal/Tests/Scripts/TestSiteApplicationTest.php:47
This can be mitigated by setting the SIMPLETEST_DB variable in phpunit.xml, but this ruins the isolation between unit and kernel tests.
2) This test is never run by run-tests.sh
Since it lives in core/tests/Scripts, the test is not discovered when run-tests.sh runs tests.
You can see evidence of this in this recent HEAD test. See the actual tests that were run which does not include TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...
Versus the test list generated for that same build which lists TestSiteApplicationTest: https://dispatcher.drupalci.org/job/php7_mysql5.5/5506/artifact/jenkins-...
Here's an issue about fixing that discrepancy: #2878269: Modify TestDiscovery so the testbot runs all the tests
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
↧
Add crop anchor option to Scale and Crop image effect
Problem/Motivation
It would be useful if the Scale and Crop image effect had an anchor option, similar to the basic Crop image effect. The anchor type, such as "center-center", is used to set the top left coordinates of the crop area. Currently, Scale and Crop crops only to the center of an image.
Proposed resolution
Have the ScaleAndCropImageEffect descend from CropImageEffect which provides the anchor option, (rather than ScaleImageEffect which it descends from currently) and do the extra math.
Remaining tasks
Write patch with tests- Review
- Commit!
User interface changes
The "Scale and crop" image effect now gives the option of choosing an anchor - it works exactly like the "Crop" image effect (which the plugin is descending from).
API changes
This adds a backwards compatible change to the 'scale_and_crop' image toolkit operation: it now can optionally accept 'x' and 'y' arguments to give an offset.
This really only affects people who are implementing image toolkits (like the ImageMagick module), who will need to do something with these arguments if provided.
Data model changes
This adds the "anchor" key to the plugin configuration for this image effect. The default value is "center-center" which matches the old behavior, so if someone imports an images style which with a "Scale and crop" effect that doesn't have the "anchor" key, it'll automatically get set to "center-center".
In short, old configuration will continue to import just fine with no change in behavior.
But tests that look at the configuration will see the new key, and on export the new key will be added. This is the cause of the majority of the test changes, and the changes to the config files in the demo_umami profile.
↧
↧
Fix typos in core.api.php and correct incorrect @see
I thought that there was an automatic spell checker; I'm not sure how this was missed and whether I should be filing this under a different META issue.
In hook_queue_info_alter docblock. There is a typo processesed. Also there is a incorrect @see \Drupal\Core\QueueWorker\QueueWorkerInterface which should be \Drupal\Core\Queue\QueueWorkerInterface
↧
rendered entity as core field format
can we make this module part of core?
https://www.drupal.org/project/contact_storage
specifically rendered entity method from this post.
https://www.flocondetoile.fr/blog/drupal-8-inject-contact-form-inside-co...
↧
Replace menu images with Libricons
Follow-up to #2405057: Replace arrow-asc and arrow-desc images with Libricons and implement using CSS
Replace these icons with the Libricon SVGs:
* menu-collapsed-rtl.png
* menu-collapsed.png
* menu-expanded.png
* menu-leaf.png
See: #1356602: [META] Clean up icons in misc
Remaining tasks
* Review/screenshots in stark.
Beta phase evaluation
| Issue category | Task because it's code cleanup |
|---|---|
| Unfrozen changes | Unfrozen because it only changes HTML/CSS |
↧
Documentation for the format of #default_value of the date form field is incorrect
The documentation for the date form element mentions that the default value should be passed as an array but this is not correct, it should instead be passed as a string in the format 'YYYY-MM-DD', which is ISO-8601 extended.
↧
↧
Clean up locale CSS inline with our CSS standards
Problem/Motivation
See: #1995272: [Meta] Refactor module CSS files inline with our CSS standards
Proposed resolution
The page in question can be seen on admin/reports/translations after language modules are enabled.
Review the CSS against our standards, see:
http://drupal.org/node/1887918#best-practices
https://www.drupal.org/node/2408617
#1190252: [573] Use csslint as a weapon to beat the crappy CSS out of Drupal core
Remaining tasks
Run CSSlint against the new CSS
User interface changes
None
API changes
None
↧
Use new Transliteration functionality in core for file names
Follow-up to #1842718: Use new Transliteration functionality in core for machine names
As a follow-up to #567832: Transliteration in core, we now have a Transliteration class in Core.
@catch mentioned in #1314214: MySQL driver does not support full UTF-8 (emojis, asian symbols, mathematical symbols) we may want to transliterate filenames in core, so that we can have a database-level unique constraint on the URI field in the database. (However, this would presumably mean that transliteration of the field could not be optional).
↧
Fix Drupal.Array.Array.LongLineDeclaration coding standard
Part of #2571965: [meta] Fix coding standards in core.
Problem/Motivation
For easy reading is a Drupal Best Practice break one per line if exceed 80 chars (columns). In this case exists 642.
Screenshot:
Proposed resolution
I fixed the Long Array for one item per line.
The patch with the fix it's in the attachment.
https://www.drupal.org/files/issues/long_array_fixed_for-2901306-2.patch
Remaining tasks
None
User interface changes
None
API changes
None
Data model changes
None
↧