Part of meta-issue #2016679: [Meta] Expand Entity Type interfaces to provide methods.
See the detailed explanations there and look at the issues that already have patches or were commited.
Add get*, set* and additional methods as it makes sense to replace the public properties (e.g. isSomething() and something())
PIFR uses Drush to install a parent site for running tests + to enable the Simpletest module.
PIFR only has to do that, because the run-tests.sh script requires an existing parent site + simpletest.module to exist and be installed.
This causes a circular dependency for a whole bunch of major D8 core patches, because they cannot be committed
→ Deadlock.
Enable run-tests.sh to (also) operate without a pre-installed Drupal site.
run-tests.sh gets two new (optional) parameters:
--sqlite: Specifies a pathname for a SQLite database to use for the test runner (Simpletest).
This database file is created automatically, and the Simpletest module schema is automatically created in it.
--dburl: Specifies the database connection info to use within actual tests.
This is needed, because otherwise, all tests would actually run against the SQLite database of the test runner, instead of e.g. MySQL.
If there is a working Drupal installation with Simpletest module already, then run-tests.sh continues to function like previously.
I.e., it uses the database connection info from settings.php and no extra parameters need to be specified.
To run tests without a pre-installed Drupal site, using a SQLite database file in /tmp and using MySQL with username 'drupal' and database drupal8 on localhost for actual tests:
php core/scripts/run-tests.sh --sqlite /tmp/test.sqlite --dburl mysql://drupal:drupal@localhost/drupal8Part of meta-issue #2016679: [Meta] Expand Entity Type interfaces to provide methods.
See the detailed explanations there and look at the issues that already have patches or were commited.
Add get*, set* and additional methods as it makes sense to replace the public properties (e.g. isSomething() and something())
Would like the ability to enable twig debugging options (normally set in the settings.php) to be in the UI.
Updated: Comment #N
#2153891: Add a Url value object added the new value object, but Entity is still passing around an array.
Switch the return signature.
N/A
N/A
Entity::urlInfo() now returns \Drupal\Core\Url
From #1927608-197: Remove the tight coupling between Block Plugins and Block Entities by @catch:
It's also weird that we specify both the plugin and the module in block config but that predates the patch so meh.
I agree with catch. It seems weird that block plugins require 'module' to be passed as configuration rather than figuring it out some other way.
All this functions are deprecated in #2109287: Replace list_themes() with a service.
So let's clean-up their usage
Updated: Comment #0
#2099363: Allow single config files to be imported and exported (Resolve regression from Views in Drupal 7) adds the ability to import single config entities.
Once committed, it will require you to have the ID specified in the YAML you are importing, which is a reasonable expectation.
However, in D7 Views, it let you choose to rename it anyway, and we could possibly do that here too.
The biggest problem would be conveying that they shouldn't include the config prefix, but that could be solved by adding a field_prefix to FAPI on AJAX.
Add a textfield allowing a custom ID that would override any set in the YAML
Decide if it should be made required
Yes
No
Not sure if this qualifies as a bug, since it generates a "notice" and not an "error." However, after upgrading to version 7.26 of drupal core, I began seeing the following notice with increased frequency in the logs:
Notice: Undefined property: stdClass::$nid in node_tokens() (line 112 of /home1/zonesny/public_html/modules/node/node.tokens.inc).
If I hack the node module (just to test and temporarily quiet the logs--I know this goes against the Prime Directive), and add a check for the value of nid, then I no longer see the notice.
/* Made the following change to line 105 in node/node.tokens.inc., based on <a href="https://drupal.org/node/1817992" title="https://drupal.org/node/1817992">https://drupal.org/node/1817992</a> */
// if ($type == 'node'&& !empty($data['node'])) {
if ($type == 'node'&& !empty($data['node']) && !empty($data['node']->nid)) {Updated: Comment #3
In our schema definitions we can either declare text as type 'varchar' if it's not very long (~ single line textfield) or as type 'text' if it can be long (~ multi-line textarea). Many textareas have a text format attached to them and this is stored in the schema along with the actual text in a separate format column.
The current field items in core are as follows (the table shows the respective plugin IDs):
| Schema type | Without format column | With format column |
|---|---|---|
| varchar | string | text |
| text |
|
As can be easily seen this is incomplete.
A field type with schema type 'text' without a format column is needed.
Provide a field type with schema type 'text' without a format.
To be as consistent as possible with the current naming scheme (which is not very consistent; see above), a plugin ID of string_long is used.
Updated: Comment #0
In #2005716: Promote EntityType to a domain object, we are adding an AnnotationBase class. This is due to the newly expanded AnnotationInterface.
The Plugin class, which is the one extended by 95% of core, returns an array.
This is fast and easy, but may turn out to be a mistake in the long run.
The current base class is abstract and does not implement the get() method.
We could make it concrete, and implement get() with a best-practices approach.
The new EntityType annotation class delegates to another class.
The annotation class could also just return itself.
Decide what is best practice, implement it.
N/A
API addition only.
more info: http://marcjschmidt.de/blog/2014/02/08/php-high-performance.html
" almost 2.000 requests/s instead of 130 on a large Symfony app."
theme_get_setting() expects that each theme has a $theme.settings default config file.Currently, drupal core’s menu blocks just print an entire tree of the specified menu. If you want just a part of the that tree, you can't do that with menu.module's blocks. Its all or nothing.
But look at drupal's themes. They have special variables that can show the primary or secondary levels of a menu. (The secondary level of a menu is just the children of the active primary menu item.) Doesn't it seem odd that we can't reproduce even this simple use case with menu.module's blocks?
Let's look at another common scenario: graphic designs for websites often have the primary links as a list of links along the top and then have the 2+ levels of the menu in a sidebar. Again, not possible with core menu.module blocks.
Since the menu.module holds all the navigation links, Drupal core should enable site admins to expose these links in any way that their site architecture requires. Right now, we are only enabling a single navigation style on sites. Talk about “that site looks like a Drupal site”!
Also, menu.module pollutes the admin/build/blocks admin page by adding a block for each menu in the system. Even if you don't use any of those blocks. I've had sites with 7-8 menus, and all those unnecessary blocks on the blocks admin page hurts the javascript performance. :-p
Fortunately, the Menu Block module in contrib has all the necessary configuration to allow flexible menu-based navigation as blocks. It also only adds a block to the block admin page when you actually want a menu-based block and not before.
So, we should move Menu Block module's functionality to core.
Icons are not alligned properly with the corresponding text in several pages.
This issue is related to #2208319: Icon misaligned in admin/reports/updates
To reproduce the bug go to admin/config.
To reproduce the bug go to admin/report/status.
To reproduce the bug go to admin/report/updates/update and go back one page.
.png)
Align icon with label.
?
New icon alignment.
None.
No warning is given if Drupal 8 is installed without the URL rewrite module enabled. This results in a seemingly broken installation for users without this module enabled.
I feel this issue warrants a major priority because Drupal appears to install correctly but results in fundamental issues that could be difficult to debug for a novice, and may happen quite regularly as Apache usually installs without rewrite enabled by default. This issue is a re-attempt at what was attempted in #1878884: Drupal8 doesn't warn you if apache rewrite is turned off which I have now closed.
I also understand (please correct if wrong) that:
The fix should make things better but further issues may be worth raising to:
Use the .htaccess file to rewrite to a new URL with an appended parameter. Installation process will then check for this parameter. If it is present, rewrite module is installed and working properly. If it is not present, then a warning is shown to the user that the rewrite module is not installed and they are given a link to more information on clean URLs and suggestion to try URLs prepended by index.php if they have problems.
Reviews needed to accept a final form of the patch
New warning shown during install process if rewrite module is not installed.
None.
Updated: Comment #7
Noticed while working on #1898442: picture.module - Convert theme_ functions to Twig
According to the specification for the picture element, there shouldn't be alt or title attributes on the picture tag.
The alt attribute belongs on the img element.
There may be further changes required to match our usage of picture with the evolving standard, which would be handled by another issue. However the alt attribute is currently causing an issue with the Twig conversion #1898442: picture.module - Convert theme_ functions to Twig. Removing alt allows us to proceed with that conversion.
Reference: http://picture.responsiveimages.org
Remove the alt from picture html element.
create patch to remove alt attribute from picture tag. update the code that generates the html and the tests for picture alt.
No.
No.
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.
The following line from twig.engine is no longer needed now that TwigReference is gone via #2114563: Remove TwigReference with the help of 'without' filter replacing 'show'/'hide' functions.. When dumping all available variables in a Twig template _references shows up.
<?php
$variables['_references'] = array();
?>Remove the line.
n/a
n/a
Issue #1898442 by Cottser, duellj, kgoel, tlattimore, cyborg_572, rwohleb: picture.module - Convert theme_ functions to Twig.Use Twig instead of PHPTemplate
| Theme function name/template path | Conversion status |
|---|---|
| theme_picture | converted |
| theme_picture_formatter | converted |
| theme_picture_source | converted |
Variable changes:
theme_picture: 'path' changed to 'uri'.
theme_picture_source: 'dimension' changed to 'dimensions'.