Part of meta-issue #2016679: [Meta] Expand Entity Type interfaces to provide methods
↧
Expand TermInterface to provide methods
↧
Trays without headings throw a JavaScript error when the non-existent heading text is accessed
Problem/Motivation
The bug was discovered while backporting to Navbar. A tray without a heading will raised a JS error because we attempt to access to the text node of the element before establishing if the element exists.
The image above shows the Inspector in Chrome just as the error is about to occur in the onActiveTray method in navbar.js.
Proposed resolution
Add a check for the element before accessing its text content.
User interface changes
None.
API changes
None.
Original report by @jessebeach
↧
↧
Move email and number field types to \Drupal\Core\Field, remove modules
Updated: Comment #0
Problem/Motivation
Part of #2150511: [meta] Deduplicate the set of available field types.
Proposed resolution
Move email and number modules code into \Drupal\Core\Field\Plugin\Field.
API changes
removal of email and number modules
↧
Saving a node with many images: node gets unpublished
Hello,
I use the image module ("image field" - drupal 7 core) to store images in a node. In rare cases, there are up to 150 images stored in a node.
Drupal seems to have a problem with so many images (for example 140) in a node:
- If I edit the node (for example add some text to the body field) and save it again, the node gets unpublished.
- I edit the node again and click "published". But after saving the node, it is still unpublished.
- I can only publish it on the page ".../admin/content"
This only happens with nodes that have lots of images.
Is this a general problem or perhaps a problem with my server settings?
↧
Update content of views tour to align with stanards
Problem/Motivation
The tour of the views config page has some grammar issues and also needs to be updated to align with emerging tour standards.
Proposed resolution
Update the tour to clean up tips.
↧
↧
Figure out a good place for _menu_link_translate
Updated: Comment #N
Problem/Motivation
Proposed resolution
Remaining tasks
User interface changes
API changes
↧
Replace element_children with Element::children in Views/Views UI
Because element_children is deprecated and we have a Drupal\Core\Render\Element class to replace it (children() method).
↧
Implement built-in support for internal URLs
Updated: Comment #64
Problem/Motivation
The contrib link modules Link, URL Field and CKEditor Link supports both internal and external URLs and a lot of people use the module for internal links. Right now, the storage for the core link field data and the default widget only supports external URLs.
Proposed resolution
Implement plan C, described below.
Remaining tasks
None.
User interface changes
A new option appears in the link field instance edit page. See screenshot from comment #64.
API changes
- both internal and external URLs can be stored (and edited in the default widget) by the link field
- the field type plugin receives its own interface (LinkItemInterface), which contains an isExternal() helper method
Original report by @Dave Reid
Current summary from #1778858: Decide on built-in support for internal URLs which was filed against the URL module issue queue:
Plan A:
- Decide we only want to support external URLs in the widget and change nothing. Leave internal URL widget for contrib.
- Pros: Lowest complexity
- Cons: Users may find out-of-the-box solution limiting.
Plan B:
- Rename the current widget from 'URL field' to 'External URL field' and add a new 'Internal URL field' widget.
- Pros: we support both, not too much extra code
- Cons: this makes a specific instance only able to use one or the other and not mix.
Plan C:
- Add an option on the field instance to have the administrator say if this field supports internal only, external only, or both. The default widget will change it's validation based on the options.
- Pros: Able to mix/match. Seems better as a field instance setting, not a widget setting.
- Cons: Most amount of complexity to add. Widget will not be able to support HTML5 'url' FAPI type if option is not 'external only' since the url field by nature only supports external fields.
Plan D:
- Always use the FAPI 'url' type, and attempt to resolve what are 'local' URLs to un-aliased internal Drupal URLs.
- Pros: Simplicity. We are able to handle both types with the same widget and use the new HTML5 FAPI type always.
- Cons: Medium complexity.
- How does this work for sites that have multiple domains (multisite or domain access) or SSL? Would we still want to add additional logic for 'Allow the following types of URLs: [X] Internal [X] External'?
↧
Z-Index inconsistency and overlapping
This issue is related to #935738: z-index conflict between block context menu & overlay.
The z-index of the contextual links are set to 900. The toolbar has a z-index value of 600. This means that the contextual link gear wheel icon appears on top of the toolbar and shortcut bar. It does this for all contextual links I can find. There was one time I couldn't get it to break, but I can't recreate that anymore.
To recreate this issue, create a node that takes up enough space to cover the entire height of the page. Hover over the node to make the gear wheel appear, then scroll up. I would expect it to disappear when it reaches the toolbar, but it appears on top.
I suggest we be consistent with z-index extremes. Setting something to 900 is okay, but consider incrementing the various Drupal core elements by 5 so that they overlap the way we want them to? (ie. contextual links = 900, overlay = 905, toolbars = 910, etc).
↧
↧
Rely on Twig auto-escape, don't prepare wasted variables in preprocess
Part of meta issue
follow-up from #1696786: Integrate Twig into core: Implementation issue
Twig as it stands introduces a fair bit of overhead into the theme system. Fabianx indicated that a lot of this is from marking $variables as secure so they're not double escaped later.
Ideally, if Twig autoescape is going to be enabled, then we should just pass raw variables to it and let it do the work. This way, if a template doesn't print the date, or a link, or whatever might currently be check_plain()ed in preprocess, we're not spending all this time creating it for it to be never used. In general, we should be able to remove a large chunk of preprocess work, and just let Twig sort out variables on demand.
Doing this means that a PHPTemplate engine in contrib is going to have to add back a way to securely format variables, but I don't see a way around this if we don't want a serious performance regression.
Related
#1818266: [meta] A secure theme system (with twig)
#1382350: [meta] Theme/render system problems
↧
Allow usage of entity_reference field widget and formatter for base fields
Updated: Comment #0
Problem/Motivation
There's core ER field that used for base fields but when entity_reference module is enabled there's no way to re-use widget and formatter
Proposed resolution
Properly pass field definition and rename outdated $instance argument.
Provide example if base ER field.
Remaining tasks
Commit patch and proceed with #2107243: Decouple ER selection plugins from field definitions
User interface changes
no
API changes
no
↧
Covert all form menu items to new form builder in form_test module
Part of #1971384: [META] Convert page callbacks to controllers
Convert below form callback to new form builder.
_form_test_checkbox_form_test_disabled_elements (requires more significant changes)
_form_test_input_forgery
_form_test_tableselect_colspan_form
_form_test_tableselect_empty_form
_form_test_tableselect_js_select_form
_form_test_tableselect_multiple_false_form
_form_test_tableselect_multiple_true_form
_form_test_vertical_tabs_form
For instructions on how to convert a page callback into a controller, see the WSCCI Conversion Guide.
↧
Write tests to ensure that all classes in Drupal can actually be found by the autoloader
Problem/Motivation
The new PSR-0 autoloader in Drupal 8 is very fragile in that it requires an exact match between the class name, namespace and location in the filesystem in order to work. If there is a typo in any of those, the class will not be loaded.
For runtime classes, this is generally less of a problem, since if your class fails to load, you'll notice it pretty quickly in most cases (although even then, there are some where you won't, such as those involving dynamic class names that are optionally loaded).
However, for simpletests, this is a major problem. If the class doesn't load, the tests simply won't be run by the testbot at all.... It will be like the test was never written in the first place.
This is more than a theoretical concern, since it's already happened several times. The ones I know about are:
- #1591296: Convert contextual tests to PSR-0 (patch was RTBC before anyone noticed)
- #1598602: Fix the path of Queue tests (patch was committed before anyone noticed)
- #1598552: Move batch tests to the right directory (patch was committed before anyone noticed)
and, one more special one...
- #1598620: Convert uuid.test to PSR-0 (nobody noticed yet - the patch in this issue actually reveals the bug!)
Proposed resolution
Write a test that looks through the "lib" directories of all core modules and ensures that all classes which it finds there can actually be found by the PSR-0 autoloader.
Remaining tasks
An initial version of the patch is already written and will be attached in the first comment.
It should work as is, but currently only runs on core modules and isn't easily extensible. We should consider refactoring it into a helper class (to run the tests on a set of locations in the filesystem) and a subclass (to specifically run the test on core modules). This would allow us to also use this to test the "core/lib" and "core/vendor" subdirectories (thereby making the Symfony autoloading tests in #1598610: Convert symfony.test to PSR-0 and remove all the files[] instances in system.info obsolete), as well as core themes, etc. It would also be possible to test all contrib modules on a particular site with this too.
Also, this test is going to use up a lot of memory (since it loads up pretty much every file in the codebase and checks them for classes). If that's a concern, we could break it up into separate test classes, perhaps, each only doing a subset of modules.
This should be backportable to Drupal 7 also, although it's less necessary there since the class registry is less fragile in this regard. But if you forget to list a new test file in the .info file, the same kind of problem can occur, so it wouldn't hurt to backport.
User interface changes
None.
API changes
None.
↧
↧
Write script to automate replacement of deprecated functions where possible
many deprecated functions can be replaced by an equivalent call to the \Drupal class. rather than doing this manually and rerolling every time a patch breaks we should automate this and run the script at a time when the patch is likely to get committed. if we can make one big patch replacing lots of different functions then that will also prevent other issues needing multiple rerolls.
↧
install_profile_info() removes required module instead of profile module from dependencies
Problem
When creating a distribution profile that only specifies e.g. Block module as a dependency, then installation succeeds, but when visiting the site, you get the following fatal error on
/user/1:Fatal error: Class 'Drupal\entity\Entity\EntityViewDisplay' not found
in \core\lib\Drupal\Core\Entity\EntityViewBuilder.php on line 225
Cause
Entity module does not get installed.
This happens, because
install_profile_info()assumes that the array returned bydrupal_required_modules()would include the installation profile as the first element, so it usesarray_shift()to remove the element.But when installing with a distribution profile,
install_profile_info()happens to get invoked before$install_state['parameters']['profile']is set, sodrupal_get_profile()does not return a "current" profile (yet).In turn, the
array_shift()causes the Entity module to get removed instead of the assumed installation profile module.
Proposed solution
Use
array_diff()instead ofarray_shift().
↧
[meta] Replace calls to check_plain() with Drupal\Component\Utility\String::checkPlain()
Instructions
This is part of #2093143: [meta] Remove calls to @deprecated and "backwards compatibility" procedural functions from core
Writing patches
We want to replace calls to check_plain(), and any references in the documentation, to Drupal\Component\Utility\String::checkPlain()
To do this, we don't want to have to write the whole "Drupal\Component\Utility\String::checkPlain()" every time so we want to use namespace aliases so that we can simply write String::checkPlain() - see the PHP documentation http://www.php.net/manual/en/language.namespaces.importing.php
We need to be sure that each file that needs to use String::checkPlain() has the statement use Drupal\Component\Utility\String; at the top of it.
Automatic patching
Instead of doing taking the manual approach I decided to create a tool https://gist.github.com/grom358/9106837 . It could be improved, possibly using the Grammar Parser project? It works by going through the tokens from token_get_all looking for calls to the function and if so inserting a use declaration and changing the function call.
~/dev/drupal $ ~/function_replacer.php 'Drupal\Component\Utility\String''StringUtil''check_plain''checkPlain'
Converting existing patches
IMPORTANT: Most of the work for this issue has already been done in #2089465: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/A-L and #2089471: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/M-Z (except system/simpletest) but because the patches touched basically all of core they needed to keep being re-written. For that reason we are splitting those issues into per-module issues but the code changes in the patches from the large issues should be re-cycled as much as possible.
Issues
Needs work:
Postponed on "Disruptive Day":
- #2089471: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/M-Z (except system/simpletest)
- #2196817: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in comment module
- #2196835: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in entity_reference module
- #2196839: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in field/field_ui module
- #2196841: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in file module
- #2196893: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in filter module
Done!
- #2187829: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/views
- #2093167: Deprecate check_plain(), call \Drupal\Component\Utility\String::checkPlain() directly instead
- #2089461: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/lib
- #2089465: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in core/modules/A-LAssigned to: thedavidmeister
- #2196797: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in action module
- #2196801: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in aggregator module
- #2196805: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in ban module
- #2196807: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in block module
- #2196811: Convert all calls to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in book module
- #2196815: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in color module
- #2196895: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in forum module
- #2196897: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in image module
- #2196901: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in language module
- #2196907: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in link module
- #2196909: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in node module
- #2196951: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in picture module
- #2196995: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in rest module
- #2196821: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in contact module
- #2196825: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in content_translation module
- #2196831: Convert all calls & docs references to check_plain() in core to Drupal\Component\Utility\String::checkPlain() in edit module
↧
Remove all calls to drupal_json_decode(), use \Drupal\Component\Utility\Json::decode()
↧
↧
Improve ContentEntityBase::id() for better DX
Updated: Comment #0
Problem/Motivation
Currently the most of cotent entities should implement id() method when their primary key is not ID
Proposed resolution
Let ContentEntityBase::id() to get id name from entity annotation entity_keys
↧
Remove deprecated drupal_explode_tags() and drupal_implode_tags()
↧
Move Drupal\Core\KeyValueStore\State* into Drupal\Core\State\State*
Problem
- The
Stateclass and interface was placed into theKeyValueStorecomponent, even though it is a higher-level implementation that involves more application-specific business logic (caching).
Proposed solution
- Move
Drupal\Core\KeyValueStore\State*intoDrupal\Core\State\State*.
Notes
- #2202477: Make FieldInfo implement a new CachedStateInterface introduces a new
Drupal\Core\State\CachedStateInterface, which is 100% inappropriate to place intoKeyValueStore.
↧