Problem/Motivation
There are no PHPUnit tests for the config class
Remaining tasks
Create PHPUnit tests to check that the config class is working as expected
↧
Add PHPUnit tests for Config class
↧
Enable node render caching
Updated: Comment #0
Problem/Motivation
Entity rendering got a lot slower in Drupal 8 (citation/numbers needed). That's why we worked very hard on #1605290: Enable entity render caching with cache tag support. That issue solved the problem for most entity types… but not for the most commonly used entity type of all: nodes.
Render caching for nodes is blocked on:
#914382: Contextual links incompatible with render cache(yellow because work on a D7 backport is being done, it is fixed in D8- #1991684: Node history markers (comment & node "new" indicator, "x new comments" links) forces render caching to be per user
- #1605290: Enable entity render caching with cache tag support
- #2099133: Comment form on same page as comments forces node render caching to be per user
- #2090783: Run comment op links (delete, edit, reply, approve + contrib) through #post_render_cache to prevent render caching granularity being per-user
- #2151439: Run node op links ("Read more", "Add child page", "Printer-friendly version", "X views" + contrib) through #post_render_cache to prevent render caching granularity being per-user
- #1979468: ".active" from linkGenerator(), l() and theme_links() forces an upper limit of per-page caching for all content containing links
- #2151457: Comment pager breaks the render cache
Many of these only became fixable after #2118703: Introduce #post_render_cache callback to allow for personalization without breaking the render cache landed a few weeks ago. We're almost at the point where can finally enable node render caching :) That will happen here!
Proposed resolution
Enable node render caching once all blockers have been fixed.
Remaining tasks
Fix all blockers.
User interface changes
None.
API changes
None.
↧
↧
Various code cleanups for the new shortcut entity
The patch in #2021779: Decouple shortcuts from menu links started a looong time ago and it was the reason for introducing ControllerBase/FormBase IIRC, but the patch wasn't updated to make use of the new shiny. Let's do it here.
↧
Bogus tests without test methods are reported as successful tests
Discovered via #2175459: Convert Drupal\system\Tests\InstallerTest into a new Drupal\simpletest\InstallerTestBase
InstallerTranslationTest is supposed to fail with this patch, because it does not define any test* methods, and thus, the test is not actually executed.
Hopefully that's the only test.
#2201783: Simplify execution logic in TestBase::run() should be committed first.
↧
Default serialization of ConfigEntities
Entities tend to get serialized in various places : cache, forms...
ConfigEntities, being more business oriented, additionally tend to get more business specific helper methods, possibly relying on internal properties / derived data / external services, other than their raw data, and which you usually don't want to serialize.
Nice thing is, ConfigEntities have a pretty straightforward serialization format: the exported properties that end up in their CMI file...
We had to do this for Field / FieldInstance entities, that fall exactly in this case above, but the code is pretty agnostic and might make sense for all ConfigEntity types.
(since then, #2205367: [HEAD BROKEN] PHP 5.4 duplicated that same code in EntityFormDisplay - leaving the symmetrical EntityViewDisplay out).
Basically, serialize to the raw array returned by getExportProperties() (as if it was going to CMI), and unserialize by passing this array to __construct() (just as if it was read from config). Same format, different storage.
Patch once I get a node id.
↧
↧
Convert simpletest theme tables to table #type
Task
Convert the following theme functions to use the new table #type:
| Module | Theme function name | Where in Code | What is it really? |
|---|---|---|---|
| simpletest | theme_simpletest_test_table | function | table |
Related issues
↧
Simplify execution logic in TestBase::run()
Spin-off from #1411074: Setup test environment only once per test class; introduce setUpBeforeClass() and tearDownAfterClass() [PHPUnit]
TestBase::run() contains some unnecessary layers of control structure nesting, which make it hard to change the execution flow.
Attached patch performs no functional changes, and only removes the nesting:
- The test class requirements check is moved first.
- Test methods are immediately filtered upon retrieval, instead of within the foreach loop.
↧
theme_fieldset() should allow any non-empty-string #title
Currently, theme_fieldset() uses empty() to determine whether or not to display a title for the fieldset. This means that #title's such as a zero will not be displayed. The attached patch converts #title to a string and displays the title unless the string is the empty string.
↧
Configuration file name collisions silently ignored for default configuration
Problem/Motivation
If a module has a configuration file (either simple config or config entity) that already exists in the active configuration it will not import. The current code just moves on see https://api.drupal.org/api/drupal/core!includes!config.inc/function/conf... especially
foreach ($config_to_install as $name) {
// Only import new config.
if ($target_storage->exists($name)) {
continue;
}
//...One issue is that we have different situations where this can occur and we might want to do different things in each - which will almost be impossible.
- A user can install the node module and create a node type called forum and then install the forum module.
- A user can install the forum module and uninstall the forum module and then install it again - at the moment the config entities own by other modules are not removed - and there are tests for this.
- Module A can contain default config for field.field.node.some_field and module B can contain default config for field.field.some_field
I'd argue that in scenario 1 we'd want to prevent forum from being installed and in scenario 3 we're want to prevent module B from being installed. But we also have specific tests around forum node type preservation after disabling the forum module!
This issue was created as a result of @yched's comment https://drupal.org/comment/8196065#comment-8196065
Proposed resolution
Current patch produces a warning to the user that default config contained by the module failed to be created.
However I think we might need to go further and add a validation step prior to installing modules, themes and profiles to ensure that there is no default configuration clash.
Remaining tasks
Decide on how to resolve.
User interface changes
Potentially a new warning message.
API changes
Potentially a new way in module installation can fail.
↧
↧
duplicate case 'name': unreachable in comment_tokens(), remove one
This issue has novice tasks. If you are an experienced core developer and have multiple commit mentions, please review novices' work on these tasks rather than doing them yourself. Feedback from experienced contributors is valued.
Updated: Comment #0
Problem/Motivation
There are two 'name' case's in comment_tokens() in core/modules/comment/comment.tokens.inc
Proposed resolution
remove the first - since the second is better because getAuthorName() does the anonymous stuff
Remaining tasks
- (novice) make patch https://drupal.org/contributor-tasks/create-patch
- review https://drupal.org/contributor-tasks/review
User interface changes
No.
API changes
No.
↧
Make text consistent: "Add new content" -> "Add content"
There's an inconsistency on the front page of newly installed Drupal 8 sites. A link appears twice with different texts: "Add new content" and "Add content" (see graphic). A search through core shows that this inconsistency appears in several other places as well.
I propose making it consistent throughout core. My preference is for "Add content" because it's shorter and the word "new" is unnecessary.
A patch follows.
↧
StylePluginBase::getFieldValue shouldn't be protected
In #2002914: Rename Views method get_field_value() to getFieldValue() the access for getFieldValue was changed to protected (in addition to the rename). Quote from that issue:
Add protected access modifier in front of the function to adher to the new OOP standards.
I wonder why exactly? The function getField (which returns the rendered fields) is public. In a module I maintain (Views Send) I need access to both the rendered and raw fields.
If there is some unknown reason for keeping getFieldValue protected, I would like to know what the preferred work-around is.
PS! Very grateful for the work all of you do in making Drupal 8 happen.
↧
No link to add view|form mode for entity types that have no shipped modes
Updated: Comment #0
Problem/Motivation
Steps:
1) visit admin/structure/display-modes/form - only User is listed
2) manually enter admin/structure/display-modes/form/add/node - now you can add new form mode for Node
3) the same applies for view modes admin/structure/display-modes/view
Proposed resolution
Create a local action for admin/structure/display-modes/[form|view]/add route that already works but not accesible from UI
Optinally we could get rid of links under each entity
Remaining tasks
create patch and write tests
User interface changes
New local action
API changes
no
↧
↧
Create Available Tours block
Problem/Motivation
As discussed in #1921152: META: Start providing tour tips for other core modules. we should add a block that shows the Available Tours. Availability depends on whether the module they belong to is enabled.
This block should be added by default to the main help page (admin/help). This screenshot visualizes what this should look like:
Proposed resolution
Create Available Tours block
Remaining tasks
- create block. Some work on this was already done in https://drupal.org/comment/7964451#comment-7964451
- create test
- enable block by default (in standard profile?)
User interface changes
- the main help page (admin/help) will be affected
API changes
No api changes
↧
Bulk operations does not respect entity access
Problem/Motivation
Entity access checks are not performed when executing a bulk operation from entity overview pages, such as the content overview page (admin/content) or the user overview page (admin/people).
How to reproduce
For user admin view
-
Create a user (useradmin with uid 2) with the following permissions:
- administer users
- access user profiles
- Implement
hook_user_access()in a custom module and deny delete access on any user entity (see code example below). - Create an authenticated user (dummy with uid 3).
- Login as useradmin.
- Try to go the cancel page of the dummy user (user/3/cancel). You should get an access denied page, so you are not allowed to cancel the user.
- Go the user overview page (admin/people).
- Select the dummy user from the overview and try to apply the action "Cancel the selected user account(s)" on it.
You will go to admin/people/cancel and you are able to select a cancel method. If you choose, for example, "Delete the account and its content." the user is deleted although you shouldn't be able to do that.$entity->access('delete')will returnFALSEfor user 3.
For node admin view
The steps to reproduce for nodes are similar, though if the user does not have the permission "administer nodes", access to admin/content/node/delete is denied even if the user is allowed to delete the selected node.
Implementation of hook_user_access()
<?php
/**
* Implements hook_ENTITY_TYPE_access() for entity type "user".
*/
function mymodule_user_access($entity, $operation, $account) {
if ($operation == 'delete') {
return FALSE;
}
}
?>Tested against
- Drupal 8.0-alpha7
- Drupal 8.0-alpha7+223-dev (january 10, 2014)
- PHP 5.4.22
- Apache/2.4.7 (Unix)
When I was searching for existing issues, I found issues about bulk operations being incomplete, though I didn't saw it mention entity access checks:
↧
Extension System, Part II: ExtensionDiscovery
This issue/patch advances on #2185559: Extension System, Part I: SystemListing clean-up + performance; remove SystemListingInfo + drupal_system_listing()— we either skip that issue and directly go with this, or this patch can be easily rebased against 8.x with that patch.
Part I + II of #2186491: [meta] D8 Extension System: Discovery/Listing/Info
Problem
SystemListingInfo::scan()triggers an infinite recursion to itself when scanning for installation profiles, because it tries to retrieve the profile directories to be scanned, which makes no sense.- The installer scans for available installation profiles, but does not prime the static filepath lookup cache of
drupal_get_filename(), which causes the first of call todrupal_get_path()from other code to trigger yet another filesystem scan. - The results of
SystemListingare not cached, even though a subsequent scan will yield the identical results. - The results of
InfoParserare not cached, even though a subsequent info file parsing will yield the identical results. hook_system_theme_info()only exists to allow modules to ship with test themes, whereas discovering themes is and should be the sole responsibility of the extension discovery process.
Proposed solution
Replace
SystemListing[Info]with a highly performance-optimizedExtensionDiscovery:Bench: 10 scans for 'modules'
SystemListing (HEAD): 6.825 seconds
ExtensionDiscovery: 0.391 seconds- Require
.info.ymlfiles for all extension types. - Instead of scanning a particular base/origin directory (e.g.,
/sites/all) for the requested extension type only, scan it once for all extensions (of all types). - Use a highly optimized filter for the recursive filesystem scan, 100% tailored to the specific task of discovering Drupal extensions.
- Do not recurse into
'tests'directories at regular runtime (~400% performance increase on its own). - Return proper
Extensionobjects for all discovered extensions.
→ Substantial extension discovery performance increase. Installer responds like a breeze.
- Require
- Fix the installer to prime
drupal_get_filename()after scanning for installation profiles to resolve the infinite recursion problem. - Statically cache all discovered extensions.
- Statically cache the
InfoParserresults to prevent the same info files from being re-parsed again. - Replace all instances of
drupal_system_listing()withExtensionDiscovery.
API changes
All Drupal extension types (profiles, modules, themes, and also theme engines) have to supply an
.info.ymlfile in order to be discovered.- The info file must specify at least the
'type','core', and'name'properties. - The
'type'value for theme engines istheme_engine. - The
'type'property should ideally be declared first (for file parsing performance reasons only).
Example:
type: theme_engine
name: Twig
core: 8.x
version: VERSION
package: Core- The info file must specify at least the
drupal_system_listing()has been replaced withDrupal\Core\Extension\ExtensionDiscovery.Drupal 7
<?php
$available_modules = drupal_system_listing('/^'. DRUPAL_PHP_FUNCTION_PATTERN . '\.module$/', 'modules');
?>Drupal 8
<?php
$listing = new ExtensionDiscovery();
$available_modules = $listing->scan('module');
// Note that the returned entries are Extension objects, offering access to
// SplFileInfo of the .info.yml file.
// @see http://php.net/manual/class.splfileinfo.php
// For example:
$filemtime = $available_modules['node']->getMTime();
?>hook_system_theme_info() has been removed. Additional (test) themes provided by modules are discovered natively now.
(8.x-only)
SystemListingandSystemListingInfohave been removed.
Follow-up issues
- Remove
/sites/all, duplicates top-level directories. - Consider to remove core compatibility check in
ExtensionDiscovery, obsolete with Migrate in core? - Convert Database drivers into a new + regular extension type?
- Move
'type'properties in.info.ymlfiles to be defined first for performance (lead by example).
↧
Basic auth has no login flood control
The basic auth module allows brute-force login attacks.
(This is a security issue in the new basic_auth module of Drupal 8, so it is critical by definition.)
↧
↧
Replace user_authenticate with a UserAuth service... (or something)
Updated: Comment #N
Problem/Motivation
user_authenticate could do with an OO revamp.
Proposed resolution
Do it
Remaining tasks
Do it
User interface changes
None
API changes
Maybe remove user_authenticate()
↧
Convert node SQL queries to the Entity Query API
Part of #2068325: [META] Convert entity SQL queries to the Entity Query API. See the parent issue for details.
↧
Allow IntegerItem's to be unsigned
Updated: Comment #42
Problem/Motivation
IntegerItem's currently have no way to denote that they are unsigned. For certain fields, however, it makes sense to provide validation that they are unsigned and to reflect this in the field's schema.
Proposed resolution
Add an 'unsigned' setting to IntegerItem.
Remaining tasks
Make tests pass.
User interface changes
None.
API changes
The following fields are now validated to be positive using the type data validation system and the database schema:
- IDs and revisision IDs of all entities
- The refresh field of aggregator feeds
- The filesize of files
↧