Problem/Motivation

The filter Restrict images to this site checks if an image is local by trying to load image dimensions from the local file, if that fails, the image is marked as remote and removed from the markup:

      // Ensure the path refers to an actual image by prefixing the image source
      // with the Drupal root and running getimagesize() on it.
      $local_image_path = $local_dir . Unicode::substr($src, $base_path_length);
      $local_image_path = rawurldecode($local_image_path);
      if (@getimagesize($local_image_path)) {
        // The image has the right path. Erroneous images are dealt with below.
        continue;
      }

That code breaks for private:// files, because the image URL looks something like /system/files/inline-images/search.jpg, but that directory does not exist on disk.

It also breaks when using image style derivatives (particularly an issue when using a module like entity embed). The URL to the image includes a token as a query parameter, and this token is still present when checking for the file on the file system.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None. (Well, working private images.)

API changes

None.

Data model changes

None.

We are getting the following error from the aggregator module, when trying to import new items from a XML feed.

Zend\Feed\Reader\Exception\RuntimeException: Could not load extension: GooglePlayPodcast using Plugin Loader. Check prefix paths are configured and extension exists. i Zend\Feed\Reader\Reader::registerExtension() (line 590 af /.../vendor/zendframework/zend-feed/src/Reader/Reader.php).

As far as I can see it's related to the zend-feed component from the Zend Framework. The zend-feed component was updated on the 24th of May and the error could be related to that update as it concerns the Google Play Podcasts DTD.

https://github.com/zendframework/zend-feed/releases/tag/release-2.10.0

Does anyone have a clue of what to do about this? Is this an issue in the aggregator module or in the zend-feed component?

Is there a way to downgrade the zend-feed component to a previous version temporarily?

I want to pull and few threads together into an action.

The correctness of this has really bugged me in the few months since I read it....... in a good way.

https://www.drupal.org/project/drupal/issues/2937984#comment-12570221

Have an issue with a patch that updates to Symfony 4 so we can see if it passes or not.

And more publicly there have been blog post about the same idea

https://www.thirdandgrove.com/long-road-drupal-9

https://dri.es/when-should-we-release-drupal-9

The posts I summaries as

"Given the hard 2021 deadline and the desire to give contrib a year to adjust we better pick up our collective skirts and get a move on."

Please also note that a second correct perspective is to say

We have identified technical debut and parcelled it up into the form of entries in the DeprecationListenerTrait and are slowly clearing things up.

But my response is still to think ...

That is a nice, but with such a large code base there will be some green bug eyed monsters just in the cracks

We can act now with such a simple simple pipe cleaning exercise exercise.

So my first idiot style move is to change all symfony-X version numbers to "*" as see what breaks

Problem/Motivation

Tests have $this->root available, still many tests use \Drupal::root()
This should ideally wait until #2907728: Installer: Convert system functional tests to phpunit is done.

Proposed resolution

Convert them over.

Remaining tasks

User interface changes

API changes

Data model changes

Hi. I I've installed Drupal-8.0.0-beta14 and using Linux on my AWS EC2. and RDS.

I can access the Admin Menu, and use Appearance and Modules features just fine, but when I try to add content or approve a test user in the admin/people, I get:

Fatal error: Call to a member function isForbidden() on boolean in /var/www/html/core/lib/Drupal/Core/Entity/EntityAccessControlHandler.php on line 82

What can I do to resolve it?

Problem/Motivation

When updating the storage definition of an identifier field (e.g. 'id' or 'revision_id'), the primary keys are not updated properly in the SQL schema.

This was the original scope of #2841291: [PP-3] Fix NOT NULL handling in the entity storage and 'primary key' changes when updating the storage definition of an identifier field but that has expanded and changed scope significantly so that this now splits it into a separate issue (again).

Proposed resolution

Add primary keys when adding a field that is part of the primary key.

Problem/Motivation

SchemaTest::testSchema fails if a driver implements Sqlite support but is not the Drupal core driver, 'cause

      case 'sqlite':
        // For SQLite we need access to the protected
        // \Drupal\Core\Database\Driver\sqlite\Schema::introspectSchema() method
        // because we have no other way of getting the table prefixes needed for
        // running a straight PRAGMA query.
        $schema_object = Database::getConnection()->schema();
        $reflection = new \ReflectionMethod($schema_object, 'introspectSchema');
        $reflection->setAccessible(TRUE);

assumes an introspectSchema method exists, but it may not be the case.

Also, per parent issue #2877583: [Meta] Remove database specific logic from core it is desirable not to have database specific conditionals in core code.

Proposed resolution

Add a Schema::findPrimaryKeyColumns in the abstract class and its driver implementations, and call that method from the relevant test.

Remaining tasks

Review.

User interface changes

None

API changes

An additional abstract method in the abstract Schema class + driver level implementations.

Data model changes

None

It would be really useful if there was a simple test method for logging in as user 1. This would help having separate tests for permissions vs tests for functionality.

I ran into an issue where I am getting this error message when running a REST POST request from my local dev environment.
When I first issue a POST request with or wituout X-CSRF-Token set in the header, I was able to successfully POST a content, but on my second request, I now get 403 response with this error message.

{
"message": "X-CSRF-Token request header is invalid"
}

I double checked the token and its a valid value from /rest/session/token.

My workaround but crazy steps I did just to continually do a POST request for my site development:
1. Is to change my http://localhost:8080/ URL into any IP address listed in my Active Network Connection. Im using Ubuntu.

http://192.168.254.102:8080/entity/node?_format=json
http://192.168.42.1:8080/entity/node?_format=json
http://172.17.0.1:8080/entity/node?_format=json

2. I use different REST tools, postman, insomnia, ARC, then go back to step 1.

I think this happens when I upgrade from Drupal core version 8.5.2 into 8.5.3.

So I am working with the managed_file form type from FAPI and cannot figure out why the ajax request does not working and the debug info is a bit cryptic.

When I choose an image to upload and upon selection when the file is uploaded via ajax, in chrome devtools I get the following error in the console. Can provide more info if needed.

Uncaught AjaxError: 
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /signup/profile?element_parents=logo/widget/0&ajax_form=1
StatusText: Internal Server Error
ResponseText: {"message":"A fatal error occurred: Serialization of \u0027Symfony\\Component\\HttpFoundation\\File\\UploadedFile\u0027 is not allowed"}

To reproduce make a custom form (I extended FormBase) and call get to PrivateTempStoreFactory with a string to create a PrivateTempStore. Add a managed_file element in buildForm. View form in browser and select a file to upload. When the file is supposed to be uploaded via ajax, the server responds with a server 500. Same issue exists on my local development environment which is OS X PHP5.6 on apache as well as on my server which is Debian

Problem / motivation

Drupal 7 has a contributed module Entity Translation which allows to have field level translations on fieldable entities. This capability has moved to core in Drupal 8.

The scope of this issue is

• Migrate entity translation settings.

The migration of the actual translated data will be done in #2975666: Migrate Drupal 7 Entity Translation data to Drupal 8.

Remaining tasks

1. Write the patch
2. Review
3. Commit

Updated: Comment #0

Problem/Motivation

History module implemented as straight d7 port and hardcoded queries to history table all over core

Proposed resolution

Introduce swappable HistoryManager service to allow more performant implementations in contrib to figure out actual needs and help to make improvements in newer version of core.
Incorporate table structure from #1029708: History table for any entity

Remaining tasks

Implement HistoryManager and HistoryManagerInterface
Replace all usages of history table with proper service calls

User interface changes

No

API changes

Deprecated functions:
history_read($nid) and history_read_multiple($nids) - HistoryRepositoryInterface::getLastViewed($entity_type, $entity_ids, AccountInterface $account)
history_write($nid, AccountInterface $account = NULL) - updateLastViewed(EntityInterface $entity, AccountInterface $account)

Related Issues

#1029708: History table for any entity
#2078753: Add history_read_multiple()
#1991684: Node history markers (comment & node "new" indicator, "x new comments" links) forces render caching to be per user

When using drush site-install with a misconfigured system (eg: missing php5-gd) no explicit message is provided.
Ex:

$  drush8 -y site-install
You are about to DROP all tables in your 'xxx' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a while. Consider using the --notify global option.
exception 'Drupal\Core\Installer\Exception\InstallerException' with message 'Extensions PHP: Disabled
Array' in /srv/www/d8/core/includes/install.core.inc:2168
Stack trace:
#0 /srv/www/d8/core/includes/install.core.inc(1026): install_display_requirements(Array, Array)
#1 /srv/www/d8/core/includes/install.core.inc(660): install_verify_requirements(Array)
#2 /srv/www/d8/core/includes/install.core.inc(538): install_run_task(Array, Array)
#3 /srv/www/d8/core/includes/install.core.inc(115): install_run_tasks(Array)
#4 phar:///usr/local/bin/drush8/includes/drush.inc(726): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#5 phar:///usr/local/bin/drush8/includes/drush.inc(711): drush_call_user_func_array('install_drupal', Array)
#6 phar:///usr/local/bin/drush8/commands/core/drupal/site_install.inc(80): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array)
#7 phar:///usr/local/bin/drush8/commands/core/site_install.drush.inc(249): drush_core_site_install_version('myprofile...', Array)
#8 [internal function]: drush_core_site_install('myprofile...')
#9 phar:///usr/local/bin/drush8/includes/command.inc(422): call_user_func_array('drush_core_site...', Array)
#10 phar:///usr/local/bin/drush8/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#11 [internal function]: drush_command('myprofile...')
#12 phar:///usr/local/bin/drush8/includes/command.inc(199): call_user_func_array('drush_command', Array)
#13 phar:///usr/local/bin/drush8/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#14 phar:///usr/local/bin/drush8/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#15 phar:///usr/local/bin/drush8/includes/startup.inc(458): drush_main()
#16 phar:///usr/local/bin/drush8/includes/startup.inc(365): drush_run_main(false, '/', 'Phar detected. ...')
#17 phar:///usr/local/bin/drush8/drush(114): drush_startup(Array)
#18 /usr/local/bin/drush8(10): require('phar:///usr/loc...')
#19 {main}

It seems install_display_requirements use a high-level formatting system for low-level messages.

For references:

• https://github.com/drush-ops/drush/issues/2158
• #2799957: Starting Drupal installation. This takes a while. Consider using the [ok] --notify global option. exception 'Drupal\Core\Installer\Exception\InstallerException' with [error] message 'PHP extensions: Disabled Array' in /home/insasse/workspace/workstation
• #2177655: Replace theme() with drupal_render() in install.core.inc
• #2625820: install_check_translations() sometimes incorrectly returns NULL instead of array

Problem/Motivation

\Drupal\workspace\WorkspaceManager::setActiveWorkspace() is clearing the cache of all supported entity types, which is.. not very nice to say the least :)

Proposed resolution

Investigate and probably propose a separate core patch.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Migrate multilingual data from D6 and D7.

Proposed resolution

D6 migration and much of D7 is working so use those migrations, and their plugins as models for these migrations. It is preferred to improve the existing destination plugins instead of creating new ones.

Remaining tasks

Because D6 is nearing end of life, the D6 multilingual migrations are the highest priority as shown in the list below.

Top Priority

• Experimental migrate_drupal_i18n module: #2953360: Experimental migrate_drupal_i18n module

Drupal 6 nodes and configuration settings to support nodes.

• Languages: #2130307: Variable to config: language.negotiation [d7] and #2166875: Migrate D6 languages.
• Language negotiation settings: #2225293: Migrate D6 and D7 language negotiation settings
• Content type translation settings: #2225271: Migrate content type language settings from Drupal 6 & 7
• D6 Nodes: #2225775: Migrate Drupal 6 core node translation to Drupal 8
• Update D6 dump file: #2670170: Add i18n string & variable data to d6_dump

High priority - remaining content migrations

• D7 entity translation settings: #2073467: Migrate Drupal 7 Entity Translation settings to Drupal 8
• D7 entity translation content: #2975666: Migrate Drupal 7 Entity Translation data to Drupal 8
• D7 title: #2863437: Migrate Drupal 7 title data to Drupal 8
• Translations of taxonomy: #2886609: Migrate D6 i18n translations of taxonomy vocabulary/terms
• User Entity translations: #2669984: Migrate D7 User entity field translations

Medium Priority

• i18n variables: #2225477: Add migrate sources and destinations for D6 i18n variables
• i18n menu: #2225587: Migrate D6 i18n menu links
• i18n block: #2225681: Migrate D6 i18n blocks translated strings
• i18n custom block: #2909444: Migrate D6 i18n custom blocks (boxes)
• i18n custom CCK: #2959410: Migrate D6 i18n CCK fields label and description
• Taxonomy vocabularies: #2225781: Migrate D6 i18n taxonomy vocabularies
• Taxonomy terms: #2784371: Migrate D6 i18n taxonomy term language (but not yet translations)
• Taxonomy vocabulary i18n settings: #2975509: Migrate i18ntaxonomy vocabulary settings
• Taxonomy fields on translations of nodes: #2859297: Migrate d6 translated nodes with translated taxonomy
• Update D7 dump file: #2670846: Add i18n data to d7_dump
• Data related to old translated node IDs #2746527: [META] Handle data related to Drupal 6 and 7 node translations with different IDs

Low Priority

• Node revisions: #2746541: Migrate D6 and D7 node revision translations to D8
• User Profile: #2225717: Add config translation support to migrations and implement for Drupal 6 user profile fields
• D6 User profile field value option translations: #2845975: Migrate Drupal 6 user profile field value option translations
• D7 Nodes: #2669964: Migrate Drupal 7 core node translations to Drupal 8
• Deriving translation migrations: #2746517: Automatically derive auxiliary migrations
• D6 node translation source: #2746293: Migrate content_translation_source when migrating node translations
• D6 synchronized fields: #2754493: D6 synchronized fields aren't migrated properly
• D7: i18n variable: #2970845: Add migrate sources and destinations for D7 i18n variables
• D7: system site settings #2970847: i18n Variable to config: system site settings [d7]
• D7: site offline message #2970848: i18n Variable to config: site offline message [d7]
• D7: user settings #2970849: i18n Variable to config: user settings [d7]
• D7: user mail #2970850: i18n Variable to config: user mail [d7]

This past week/weekend, I went through the process of defining a D8 content entity type with bundles (because I'm working on the d8 update of my programming with Drupal book), and with a UI that allows you to do CRUD on both the entity objects and bundles.

Keep in mind that I'm kind of an outsider to entity defining in D8 -- I haven't been very involved in building the existing core system (which I think gradually evolved) or the existing core entities.

I used the existing entities as a model... but it took me hours of debugging to get it all working, and the code and routes I ended up with were still not all that great at the end of it all. Maybe there were things I didn't understand (where we need better documentation), and maybe it's just that the DX needs improvement?

Anyway, defining a UI for entities seems very complex. Between the main entity and the config entity for the bundles, this involved defining:

• 8 routes with placeholders
• Various menu links, action links, and task links
• A theme hook, Twig template, and preprocess function for displaying the content entity
• 9 classes and interfaces for the entities, their forms, and the config list controller
• A config schema for the bundle entity
• A few methods in a Controller outside the entity space
• - A URI callback function [no longer necessary]
• A permission in hook_permission()
• Views integration for the content entity, assuming you want to use Views to make an admin page similar to admin/content (I didn't actually yet even do that); then you'd want to also export your view as config.
• And I just found out that if I am using SQL storage and want it to have decent indexes, I also need to define a storage controller class; see #2326949: Move entity-type-specific schema information from the storage class to a schema handler

This process seems overly complicated, and part of the problem was that I pretty much had to do all of the above steps before I could test anything in the UI.

Here are some things that occurred to me during this process, that I thought could be improved:

• [A] I am not sure why I needed to build an editing form for the config entity, when I think it could have been built from the config schema. Could we have a standard entity form class that we could use that would do that?

  [Berdir: "Sure, that would be great" [just hasn't been done yet]

• [B] I am not sure why I needed to define an editing form for the content entity, when all it does is put up a field for the title/label, which should be pretty obvious from some other methods on the entity class etc. Could we have a standard entity form class that would do that?

  [Berdir: (paraphrasing) you can use widgets for the form elements... see example links in comment #2]

  Related issues:
  #2312133: Make EntityForm::save() save the entity
  #2230637: Create a Language field widget and the related formatter
  #2226493: Apply formatters and widgets to Node base fields

• [C] The delete confirm forms... For the config entity, that maybe had to be custom, because you have to figure out what to do if the bundle is deleted and there are entities defined in that bundle. But I don't see why the main entity delete needed its own custom form. Could we have a standard one?

  [Berdir, paraphrasing: Existing entity types have small differences in wording, so it's hard to standardize.]

• [SORRY, there is no (d)]
• [E] Routes and menu links... These could be made totally standard, given a path prefix. For instance if I said the prefix was "myentity" for the content entity, then standard routes could be made for myentity/[ID]/[op], where [op] is delete or edit or missing for the view page. For the config entity, you just need edit/delete, even easier.

  [Berdir, paraphrasing: Existing entity types have small differences, so it's hard to standardize.]

  [timplunkett, paraphrasing: Making these automatic would make it harder to understand. Right now at least all the routes for a module can be found in one place.]

  [jhodgdon: Maybe it could be made easier in the routing.yml files, something like:

  my.route.name:
    _entity_route: myentity 
    _route_type: edit
  

  ]

  Related issues:
  - #2259445: Entity Resource unification
  - #2285413: [Meta] Standardize entity route names
  - #2089757: Auto generate routing entries for entities based on an 'admin_path' and 'admin_permission' annotation
  - #2316949: Title setting in EntityViewController::view() is not working right

• [F] Theming - for the content entity, really I don't know why I had to define an entity theme for my entity type, Couldn't there be a fallback? All it does is maybe put up the title and let Field module do the rest. Couldn't that be standardized?

  [Berdir, paraphrasing: Existing entity types have small differences, so it's hard to standardize.]

  Related issues:
  - #2301245: Entity system invokes non-existing theme hooks: "Theme hook $entity_type_id not found."
  - #2270883: Automatically add theme hook suggestions for all entity types
  - #2023571: Support preprocessing in EntityViewBuilder

• [G] Config entity list builder - I think this could be standardized?

  [Berdir, paraphrasing: Existing entity types have small differences, so it's hard to standardize.]

• [H] Views integration -- I didn't actually do this yet but it seems like that could probably be mostly standardized too?

  This is actually being done on:
  - #1740492: Implement a default entity views data handler

• [I] Storage -- it seems like specification of NOT NULL for indexing efficiency could be done as part of the entity class's baseFieldDefinition() method? And maybe specification of what fields need indexes could be also on the base entity class? See #2326949-10: Move entity-type-specific schema information from the storage class to a schema handler.

Problem/Motivation

When #2922033: Use the Layout Builder for EntityViewDisplays is committed, Layout Builder will hide the ability to manage field display with the Field UI in the "Manage Display" tab, by replacing every Entity Type's entity_view_display class with its own.

While the user experience provided by Layout Builder is superior to the traditional Field UI, some Entity Types or bundles may want to "opt-in" of this functionality, for a variety of reasons:

1. A contrib module that enhances Field UI, like Field Group, is used
2. An Entity Type uses a custom entity_view_display class with logic specific to itself
3. An Entity Type or bundle isn't advanced enough for Layout Builder to make sense - i.e. it only has a handful of fields that do not need a layout
4. It could be confusing for users to suddenly have all their displays converted to the Layout Builder UI
5. As a result of the above the migration path to Layout Builder (from both Core Field UI and from c ontributing modules such as Panalizer) could be hindered somewhat and less smooth

Proposed resolution

We should have a way for Entity Types and/or bundles to "opt-in" of Layout Builder. Maybe instead of being enabled on every Entity Type, Layout Builder is only enabled when specifically "turned-on", ala Panelizer?

Remaining tasks

Discuss the problem and decide on the scope of a solution.

User interface changes

Undecided.

API changes

Undecided.

Data model changes

Undecided.

For weeks, tons of notices/warnings like the following in the Drupal watchdog:

 472306  25/May 11:29  php       notice    Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module).                                  
 472305  25/May 11:29  php       notice    Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module).                                  
 472304  25/May 11:29  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 
 472303  25/May 11:29  php       warning   Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc).       
 472302  25/May 09:33  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc). 
 472301  25/May 09:33  php       warning   Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 482 of /var/www/html/includes/unicode.inc).       
 472300  25/May 09:08  php       notice    Notice: Undefined index: #prefix in file_ajax_upload() (line 287 of /var/www/html/modules/file/file.module).                                  
 472299  25/May 09:08  php       notice    Notice: Undefined index: #suffix in file_ajax_upload() (line 284 of /var/www/html/modules/file/file.module).                                  
 472298  25/May 09:08  php       warning   Warning: trim() expects parameter 1 to be string, array given in user_pass_validate() (line 69 of /var/www/html/modules/user/user.pages.inc).

Looking at the requests from the web server logs, these entries look to be due to attempts to exploit SA-CORE-2018-002 and SA-CORE-2018-004. The fixes for those vulnerabilities should handle things more gracefully and not give notices/warnings, right?

All these notices/warnings for normal operation are masking notices/warnings the administrator may want to observe.

Currently the character я is replaced by a not by ya as expected.

See #357254: Transliteration of Russian letters as a reference for correct transliteration table.

If a custom form element adds a managed_file form element during a #process block the file_ajax_upload() function issues a notice in file.module on line 256. In file_ajax_upload() the logic is trying to get to the form element by traversing the form before the #process callback has been executed.

For instance:

function example_element_info() {
  return array(
    'example_file' => array(
      '#process' => array('example_process'),
    ),
  );
}

function media_file_process($element) {
  $element['#tree'] = TRUE;
  $element['upload_file'] = array(
    '#type' => 'managed_file',
    '#title' => t('Upload file'),
  );
}

Then when the Upload button is pressed a notice is shown:

Notice: Undefined index: upload_file in file_ajax_upload() (line 256 of /home/prarie/Documents/Workspace/Drupal/modules/file/file.module).

This looks like it will only mess up the display when a class will never get added at line 270 (and the PHP notice message) and not actual file handling.

It appears to be as simple as adding a call to form_builder before the traversing the form to find the managed_file element. Will roll a patch once I get my local environment ready to do so.