↧
Replace hidden with enabled in menu links code
↧
Remove all PNG fallbacks for SVG
Problem/Motivation
In #2286601: [policy] Drop support for browsers that don't support SVG, we decided PNGs were old news and SVG are the future.
Remaining tasks
Remove all PNG equivalents of icons in misc/icons
Removed all references to PNGs in CSS
Remove the SVG modernizr test.
User interface changes
None, for users with modern browsers
API changes
Removal of the SVG modernizr test
↧
↧
Allowed language langcode argument cached cause Error
Problem/Motivation
Noticed while manually testing #2301317: MenuLinkNG part4: Conversion
Steps to reproduce:
- Install 8.x
- set always show errors (admin/config/development/logging)
- enable custom menu links, language and content translation modules.
- Enable content translation for Custom menu links.
- Create a custom menu link.
- Add a new language.
- Go to the translate page for that menu link.
- Click add to add a translation for that new language.
- Error is "invalidArgumentException: Invalid translation language (fi) specified".
InvalidArgumentException: Invalid translation language (fi) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 746 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).
Drupal\Core\Entity\ContentEntityBase->addTranslation(fi, [Array])
content_translation_prepare_translation(Drupal\menu_link_content\Entity\MenuLinkContent, Drupal\Core\Language\Language, Drupal\Core\Language\Language)
content_translation_add_page(Drupal\menu_link_content\Entity\MenuLinkContent, Drupal\Core\Language\Language, Drupal\Core\Language\Language)
Drupal\content_translation\Controller\ContentTranslationController->add(Symfony\Component\HttpFoundation\Request, af, fi)
call_user_func_array([Array], [Array])
Drupal\Core\Controller\HtmlPageController->getContentResult(Symfony\Component\HttpFoundation\Request, \Drupal\content_translation\Controller\ContentTranslationController::add)
Drupal\Core\Controller\HtmlPageController->content(Symfony\Component\HttpFoundation\Request, \Drupal\content_translation\Controller\ContentTranslationController::add)
call_user_func_array([Array], [Array])
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Symfony\Component\HttpFoundation\Request, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Symfony\Component\HttpFoundation\Request, 1, TRUE)
Drupal\Core\DrupalKernel->handle(Symfony\Component\HttpFoundation\Request)Proposed resolution
- ?
- clear caches after adding a language
- do something to menu links so it notices new languages
Remaining tasks
Discuss problem and possible solutions
User interface changes
No.
API changes
No?
↧
Only record unique hits in node counter stats
One of my biggest long-time annoyances with Drupal is the way that the hit counter for a node behaves. The hit counter records every single page view for a node. If you reload a node/x page 10 times, then 10 hits will be recorded for that page. This is ridiculous: the hit counter system in statistics.module needs to be just a little bit more intelligent than this. It needs to identify hits that are not unique (i.e. hits from the same user/host for the same page), and to stop such hits from bumping up the counter.
Attached patch implements this checking system. With this patch, only the first hit for page 'x' from user 'y' (which can of course be an anonymous user, i.e. user 0) on host IP 'z' will increment the counter. All subsequent hits will be recognised as duplicates, and will not result in the counter being incremented. This results in 1 extra query per node page view, but the performance impact is minimal (considering that more performance-intensive INSERT queries are being run anyway, whereas this is just an extra little SELECT query). This checking only occurs if the node access log feature is enabled, because otherwise there is no way to check for non-unique page views.
↧
admin themes for translation tabs just works for nodes
Problem/Motivation
Problem: the priority of the AdminRouteSubscriber is lower than ContentTranslationRouteSubscriber
Proposed resolution
Remaining tasks
User interface changes
API changes
↧
↧
update.module - Convert theme_ functions to Twig
Issue #1898466 by joelpittet, webthingee, W1n5t0n45, ry5n, ezeedub, lokeoke, Cottser | c4rl: Update.module - Convert theme_ functions to Twig.Task
Use twig templates instead of theme_ functions for the update module.
To test this code
- Visit /admin/reports/updates or Reports > Status report and make sure that your report renders correctly
| Theme function name/template path | Conversion status |
|---|---|
| theme_update_last_check | converted |
| theme_update_manager_update_form | Removed, needed markup moved into form callback. |
| theme_update_report | converted, troubleshooting |
| theme_update_status_label | converted |
| theme_update_version | Moved to it's own issue: #2264833: Convert theme_update_version to update-version.html.twig |
Related
#1757550: [META-37 theme functions left] Convert core theme functions to Twig templates
#1938934: Convert update theme tables to table #type
#2298039: Remove all PNG fallbacks for SVG
Followup: #2099293: Update Module Twig Clean Up
Followup: #2287031: Change lcase translatable strings to ucfirst
↧
Very confusing breadcrumbs on deep admin pages
Today I was on
admin/config/development/configuration/single/export
(the configuration export page).
To get there, I went to:
Manage (top black bar) > Configuration (white menu bar) > Development (find this section, not actually a click) > Configuration management (click link) > Single import / export (click local task tab) > Export (click local action)
But the breadcrumb on the page shows, confusingly:
Home > Administration > Configuration > Development > Synchronize
Here's a screen shot:
This is just wrong:
- Manage is shown as Administration
- Configuration management is completely missing from the trail.
- Instead of showing the local task tab I'm actually underneath (Single import / export), it is showing the default local task (Synchronize).
This is very broken.
↧
Refactor user entity properties to multilingual
Based on #1498634: [meta] Define revision/translation SQL schema for core entities (no patch) there should be a new schema. The name should be users_translation it's connected to users directly.
↧
Make Book storage independent
Problem/Motivation
Book-related queries currently appear in book.module . We should move all storage-dependent code to one class to make storage swap-ability easier.
Proposed resolution
Move all queries from book.module to \Drupal\book\BookManager and make the latter storage controller for all book-related operations.
Once this is done, split operations related to the books as collection (list all books...) from the ones related to nodes within a book (book_node_load, ...) and introduce a separate storage controller for the latter (single responsibility). But this can be done after the initial hook to manager refactoring.
Remaining tasks
- move all storage-dependent node hooks to the storage controller
- validate with an alternate storage controller (see #2224725: Add a mongodb.book.manager service
- if this seems worthwile, refactor the "manager" to two classes, one for the book as collection of nodes, and one for the nodes themselves.
User interface changes
None.
API changes
None.
↧
↧
Core is inconsistent when handling two menu items with the same path. It says one thing in the UI and does another in reality.
USE CASE:
A large (very large) single hierarchical site menu occasionally wants to put some common content (eg safety references) in the local navigation in more than one section. It's OK to jump over to the main section when that link is clicked (we don't keep the breadcrumbs or anything from the copy version) but we do want to place a menu link as if it was a child of section B. The Node edit UI doesn't support that (Unless we have multiple_node_menu) but we've always been able to set that up using the Menu admin UI.
There are architectural reasons why this is not *always* a great idea, but it is possible, clients do want to do it, and there are also good arguments for continuing to support it quietly.
What should be easy:
![]()
It's always been a bit of a hidden trick getting multiple menu items that take you to the same place. It can be *done* in menu management OK, but what context you land in when you hit the node (what the expanded parent is) could only be managed by knowing the MLIDs.
In D4 and D5, we could make multiple aliases and trick it a little. But since the url_aliases started getting collapsed to the system path, that stopped working. But once you'd jiggled them, it was stable.
In D7 and D8, there is a change. I believe it's a regression, but it was to a seldom used un-feature.
The new symptom however is easily illustrated however.
Why it's a UI WTF
^ This is pure lies. It makes no sense.
menu.inc deliberately sorts the menu_link items and chooses the first consistently. That is good design. Additionally, the *first* time a page is made, that's the home for it.
Core however, is not so smart, and inside menu_link_get_preferred() it cycles through all matches, overwriting the keys with the same path until it runs out of candidates, and the most recently added duplicate menu item wins
Which means that if a menu administrator adds a shortcut to core documents from elsewhere in the site, suddenly their section owns that content and context.
Being bounced elsewhere is not the problem, that's OK when you can expect it.
The problem is that the editors UI tells them that *this* page has *this* primary menu item ... and then takes them somewhere new and wrong.
It's really hard for an editor to see what's going wrong or how to fix it.
This behavior is not intentional, and is just an oversight in the logic inside menu_link_get_preferred().
A REALLY small one-line fix - that applies to both D8 and D7 identically, will just get the system to sort its menu path link candidates so that everyone : Menu UI, Core behavior, and user expectations are in sync once more.
↧
Remove usages of watchdog() from forms, plugins and controllers
Now that watchdog() is deprecated we should remove all usage from forms, controllers, plugins
↧
use × instead of x
height and width values should be formally divided with an ×-mark (× in HTML) instead of an x
↧
Views plugins do not store additional dependencies
Problem/Motivation
#2216071: Views plugins need a way to store additional dependencies went in, which is good. However, this only really has a mechanism in place for storing dependencies for handlers, not all views plugins. We need this for other plugins such as display, style, row, cache, etc..
Proposed resolution
Get all plugin dependencies when a view is saved.
Remaining tasks
- Decide if this should be at the config entity level, or just in the views UI level.
- Plan best approach to doing this
User interface changes
None
API changes
None
↧
↧
page admin/content occured error without views module
Fatal error: Call to a member function isTranslatable() on a non-object in /drupal8/core/lib/Drupal/Core/Entity/ContentEntityDatabaseStorage.php on line 990
then back to an anothrt page
Notice: Undefined index: body in Drupal\Core\Entity\ContentEntityDatabaseStorage->doLoadFieldItems() (line 990 of core/lib/Drupal/Core/Entity/ContentEntityDatabaseStorage.php).
Drupal\Core\Entity\ContentEntityDatabaseStorage->doLoadFieldItems(Array, 'FIELD_LOAD_CURRENT')
Drupal\Core\Entity\ContentEntityStorageBase->loadFieldItems(Array)
Drupal\Core\Entity\ContentEntityDatabaseStorage->mapFromStorageRecords(Array)
Drupal\Core\Entity\ContentEntityDatabaseStorage->doLoadMultiple(NULL)
Drupal\Core\Entity\EntityStorageBase->loadMultiple()
Drupal\Core\Entity\EntityListBuilder->load()
Drupal\Core\Entity\EntityListBuilder->render()
Drupal\Core\Entity\Controller\EntityListController->listing('node')
call_user_func_array(Array, Array)
Drupal\Core\Controller\HtmlPageController->getContentResult(Object, '\Drupal\Core\Entity\Controller\EntityListController::listing')
Drupal\Core\Controller\HtmlPageController->content(Object, '\Drupal\Core\Entity\Controller\EntityListController::listing')
call_user_func_array(Array, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\HttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)↧
AccessManager should introduce constants for 'ANY' / 'ALL'
Problem/Motivation
Proposed resolution
Remaining tasks
User interface changes
API changes
↧
Convert translation metadata into regular entity fields
In #1810370: Entity Translation API improvements we agreed that entity translation metadata should be considered regular translatable (non-configurable) fields and as such should be stored in the various data tables. The conversion will need to wait for all the legacy entities to be converted to the Entity Field API and refactored to use the data table for translatable properties.
↧
Field language filter/sort/etc. for Views do not work and are not needed
Problem/Motivation
If you attempt to use a field language filter, such as "Content Body:language" in Views, it doesn't work. You get a PDO error like this from the query:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'node__body.language' in 'where clause': SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {node} node INNER JOIN {node_field_data} node_field_data ON node.nid = node_field_data.nid LEFT JOIN {node__body} node__body ON node.nid = node__body.entity_id AND node__body.deleted = :views_join_condition_0 WHERE (( (node_field_data.status = :db_condition_placeholder_0) AND (node_field_data.type IN (:db_condition_placeholder_1)) AND (node__body.language IN (:db_condition_placeholder_2)) ))) subquery; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => article [:db_condition_placeholder_2] => fr [:views_join_condition_0] => 0 )
The problem is that the field data tables have a column called "langcode" not "language". This is set up in field_views_field_default_views_data().
This problem would also occur if you use the Field, Sort, or Argument on the field language of any field. It is not specific to the Body field.
Proposed resolution
The language value for a field is closely tied to the entity translation language. There are two cases:
a) If the field is translatable, then the field language value for a particular translation is the entity translation language.
b) If the field is not translatable (whether or not the entity as a whole is translatable), presumably the field is language-neutral, and the field language value would be the same as the original entitys language (the translation source).
In case (a), we do not need to be able to filter, sort, or display the field language, because we can filter, sort, or display the language of the entity translation.
In case (b), we do not need to be able to filter, sort, or display the field language, because we can filter, sort, or display the language of the original entity.
So, we currently have one :language Views field, filter, sort, and argument per field, and they don't work. Rather than fixing the database problem and making these work, we should just get rid of the clutter and remove the ability to display, filter, or sort an entity view on the field language.
Remaining tasks
a) Agree on the best course of action: either fix the database column or remove the field language support entirely.
b) There have been patches submitted to both fix the database column problem (comment #1) and remove the language support (comment #15). If we are going to fix the problem, then the patch in #1 needs tests. If we are removing the problem, then the patch in #15 should be sufficient.
User interface changes
If we remove support for field language, these options will not be available when making Views. However, they weren't really available before because if you tried to use them, you got a PDO error.
API changes
See UI changes.
↧
↧
Remove XML-RPC
Derived from #1033818: Move xmlrpc includes into xmlrpc.module, this issue is to track the removal of the XML-RPC API in Drupal. Since there is no Blog API in Drupal core anymore, there is nothing left in core that actually makes use of the XML-RPC library, meaning there's no reason to have it left in core.
It can easily live on at http://drupal.org/node/1285602 .
↧
Refactor taxonomy entity properties to multilingual
Based on #1498634: [meta] Define revision/translation SQL schema for core entities (no patch) there should be a new schema for both taxonomy. See #1498674: Refactor node properties to multilingual for an ongoing conversion.
↧
Deprecate all of mail.inc, move drupal_mail to method on Mail plugin manager
Problem/Motivation
We're calling out to procedural code from OO stuff to use drupal_mail, eg Drupal\contact\MessageForm.
Proposed resolution
Move drupal_mail to MailManager::mail
Move all the other mail.inc stuff to a new \Drupal\Core\Utility\Mail class.
We can't make it a component because it needs Settings and references base_url global.
Remaining tasks
Fix any failing tests
Reviews
User interface changes
None
API changes
- drupal_mail() » \Drupal::service('plugin.manager.mail')->mail()
- drupal_mail_system() » \Drupal::service('plugin.manager.mail')->getInstance()
- drupal_wrap_mail() » \Drupal\Core\Utility\Mail::wrapMail()
- drupal_html_to_text() » \Drupal\Core\Utility\Mail::htmlToText()
- _drupal_wrap_mail_line() » \Drupal\Core\Utility\Mail::wrapMailLine()
- _drupal_html_to_mail_urls() » \Drupal\Core\Utility\Mail::htmlToMailUrls()
- _drupal_html_to_text_clean() » \Drupal\Core\Utility\Mail::htmlToTextClean()
- _drupal_html_to_text_pad() » \Drupal\Core\Utility\Mail::htmlToTextPad()
↧