Quantcast
Channel: Issues for Drupal core
Viewing all 298635 articles
Browse latest View live

views_add_contextual_links() references to non existent views_preprocess_page() function

$
0
0
$ grep -rn views_preprocess_page .
./core/modules/views/views.module:362: * @see views_preprocess_page()

Improve Umami demo's support for managing field display settings

$
0
0

The umami designs #2900720: Designs for the Out of the Box experience intiative were created in support of a Drupal demo that closely mimics the kind of polished layouts you find in real-world food magazine websites. Layouts for some of the features and fields are more complex and our plan is to deliver these layouts through the new upcoming layout features in core. Since Umami is to be built on stable core features only, the theme currently hard-wires some features in favour of following the designs and methods you might use if theming this type of site in a client-specific scenario.

It is our plan to demo any layout features in Drupal core as soon as they are stable. In the mean time, we have the option to revisit aspects of the original designs in order to consider better supporting the existing Manage Display field settings and display modes of Drupal core.

The main benefits in doing so are improved support for curious demo users who choose to experiment by making changes to the manage display settings, and readying the theme to be more adaptable to new core layout functionality. Since we are demoing display settings as they are today, we probably do want to ensure that any user-made changes are properly reflected and make sense in a demo context.

I believe the proposed design/layout changes on this issue will therefore help to provide a core demo that is more functional, with only limited impact on the quality of the final design. We should also be in a better position to progressively enhance the theme's design as layout modules become supported by the demo.

Proposed alterations

The following theme features are proposed to be adjusted for 8.6 and the attached visuals support these descriptions:

Article and recipe 'Card' display modes

Changing the cards will affect the front page, articles listing, recipes list and promoted items on recipe and article pages.

  1. Present the title as the first field, followed by any fields set as visible in manage display, followed by the 'view' link. Perhaps with a CSS-only exception to this field order for the 3 front page promoted cards
  2. Removal of edge-to-edge images to better support the possibility of any field being presented in a card and with more predictable presentation results
  3. Use of flexbox to progressively enhance horizontal alignment (we may have to compromise on older browsers). Following a title-first layout exposes us to the problem of different length headings dictating the alignment of subsequent fields across a row of cards. Images will, for example, be noticeably out of whack with others in the same row on larger screen widths. I've carried out some experiments in flexbox to see if we can fix this with CSS only https://jsfiddle.net/kjays/6sz1o4qp

Article content type

The article content type is affected by these proposed changes only slightly.

  1. Author and date will be displayed immediately after title
  2. Category, lead image and body will be displayed as per the content type's manage display settings
  3. Image presentation will be adjusted to fill the full width of the content column and no longer be 'pulled'. Images for the demo are currently included in Drupal core and so we need to keep their size right down (currently 768px wide). If images stretched to 100% of the container width begin looking too grainy, then max-width of the image can be limited to 768px as a compromise for now

Recipe content type

The existing layout for the recipe content type is all set to provide a great demo of upcoming layout features and as such, its current presentation needs to be more heavily adjusted in support of the existing manage display features. Proposed changes include:

  1. All fields to be presented in a single stacked column
  2. Summary moved to be the first field after the hard-wired title field
  3. Lead recipe image field continues to be sourced by a 768px wide image. I propose we limit display of this image to that width in order to avoid the image becoming way oversized and out of keeping with the purpose of the page
  4. We don't have a sidebar on this content type to restrain the width of the main content column and we will therefore end up with a lot of empty space down the right side of the content. We have the option to lessen the negative visual impact of this space by styling the wrapper for the image and ingredients fields to have some form of a background pattern/style so that at larger screen sizes, we have at least some form of feature design filling the page's width
  5. Preparation, cooking time, number of servings and difficulty fields will need to be themed as isolated field components so that they work in any placement. Icons will likely need to be included from CSS or specific field templates. (CSS is likely the preferred option given previous experiments I carried out with the field layout module)
  6. The Ingredients field is likely to always contain short lengths of content. I propose a simple flexbox (or other) 2 column list presentation with max-width and the option to background-fill the field as a band to fill the negative space
  7. The Method field can be presented as a width-limited (for easier reading) list as per the current styling.

Remaining tasks

  • Agree on whether this is a desired set of changes to make
  • Adjust the visuals for any errors or changes required from our discussions
  • Create issues to cover each of the proposed changes

Ignore: Patch testing issue

Javascript tests are failing if you override MINK_DRIVER_CLASS

$
0
0

If you define both "MINK_DRIVER_CLASS" and "MINK_DRIVER_ARGS_WEBDRIVER" environment variables as it is documented and try to run a javascript, ex.: core/modules/views/tests/src/FunctionalJavascript/PaginationAJAXTest.php then you get a PHP error:

1) Drupal\Tests\views\FunctionalJavascript\PaginationAJAXTest::testBasicPagination
An unexpected error occurred while starting Mink: array_replace(): Argument #2 is not an array

The reason is simple, the overridden initMink() function in JavascriptTestBase class checks the value of $this->minkDefaultDriverClass, but it is the default "Zumba\Mink\Driver\PhantomJSDriver" until BrowserTestBase::getDefaultDriverInstace() gets called. The problem is that it only gets called when JavascriptTestBase::initMink() calls parent::iniMink() (alias BrowserTestBase::initMink()) but it is already too late that time.

I think minkDefaultDriverClass and minkDefaultDriverArgs should be set in the constructor of BrowserTestBase rather in a separate method.

Can not uninstall Field Layout while Layout Builder is installed

$
0
0

I'm trying to uninstall "Field Layout" but I'm having errors in my terminal :

www.s1biose.com@vps000000 ~/public_html $ drush pm-uninstall field_layout
 [error]  TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install) #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}. 
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install on line 34 #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install).
 [error]  Drush command terminated abnormally due to an unrecoverable error. 

View result counter is not work in ReSTful expoert

$
0
0

hi ,i use drupal 8.5.3 and i use several content type ... i try to create app for client(android)...i need to count every content in result...but i think there is bug in views with View result counter in restful export....is bug ?

+is there another way to count every content ?tnx

Since 8.5.4 can no longer save new content

$
0
0

Referrer http://orcma.org/node/10/edit?destination=/admin/content
Message Drupal\Core\Entity\EntityStorageException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null: INSERT INTO {node_field_data} (nid, vid, type, langcode, status, title, uid, created, changed, promote, sticky, default_langcode, revision_translation_affected, is_draft) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13); Array ( [:db_insert_placeholder_0] => 10 [:db_insert_placeholder_1] => 299 [:db_insert_placeholder_2] => page [:db_insert_placeholder_3] => en [:db_insert_placeholder_4] => [:db_insert_placeholder_5] => Board & Staff [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => 1488490325 [:db_insert_placeholder_8] => 1529091489 [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 1 [:db_insert_placeholder_12] => 1 [:db_insert_placeholder_13] => 1 ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 829 of /home2/orcmaorg/public_html/core/lib/Drupal/Core/Entity/Sql/Sql

https://www.drupal.org/forum/support/post-installation/2018-06-15/can-no...

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony

$
0
0

Pages are not shwoing up with the follwoing error:

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of /home/progonat/public_html/domain.com/vendor/symfony/http-foundation/RedirectResponse.php).

On page:
The website encountered an unexpected error. Please try again later.InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of vendor/symfony/http-foundation/RedirectResponse.php).

I also noticed that the LOGO and HOME in the main menu do not redirect to the front page but instead they redirect to the current page, which is not correct.

Any help or insight will be greatly appreciated.


Replace SimpleAnnotationReader with a Drupal Annotation component class

$
0
0

Follow-up to #2421451: Drupal needs comments in opcache

Problem/Motivation

SimpleAnnotationReader loads classes while parsing them. This puts more things in the opcache than we would like.

Doctrine has essentially "won't fixed" this bug, since they're planning to deprecate SimpleAnnotationReader.

AnnotationReader itself both loads classes and uses reflection, this is much too memory heavy for Drupal given the number of plugins in core, and is the reason we contributed to SimpleAnnotationReader in the first place.

At this point, we are only using SimpleAnnotationReader so that it can parse the docblock, which we then pass on to other code which does not use reflection.

Doctrine's support cycle is out of sync with ours, since they already require PHP 5.6.

Proposed resolution

We need our own annotation parser, as a component, which uses the PHP tokenizer rather than reflection and doesn't load any classes as PHP.

The drupal/core-annotation subtree split will allow other projects to use that if they wish.

Some Analysis

Drupal\Component\Annotation\Plugin\Discovery\AnnotatedClassDiscovery:: getDefinitions() uses a Doctrine\Common\Annotations\SimpleAnnotationReader to get the annotation from the class declaration: http://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Component/Annotat...

SimpleAnnotationReader::getClassAnnotation() requires a ReflectionClass which causes the class to be loaded. That's the problem we're trying to solve.

Then the reflection object is used to get the docblock, because it's super convenient. :-) It also eats up memory and op cache.

So basically our replacement should not require a ReflectionClass for SimpleAnnotationReader::getClassAnnotation(). We already have the path, so instead of generating a ReflectionClass (with MockFileFinder and StaticReflectionParser), we should pass in the path. It then does token parsing to find the class declaration and the docblock immediately before it.

Remaining tasks

User interface changes

API changes

Data model changes

Allow preferred language selection for link field

$
0
0

Problem/Motivation

In multilingual sites it's currently not possible to select a specific translation for internal path's when creating links. For instance, I have a Dutch/English site:

  • Node 1 is the homepage and has a translation for both languages.
  • Node 2 is a Dutch node with a link field set to link to node 1.
  • When showing the link on node 2, I want the link to go to the English translation of Node 1.

I ran into this while trying to find a solution for #2845245: Allow Redirecting to another language.

This seems to be related to the following issues:
#2462279: Language prefix for custom menu link paths are saved but not used - The menu link doesn't use the entered language prefix, having a seperate language selection field will make the destination language explicit.

#2466553: Untranslated menu items are displayed in menus - Menu links can have a language and it would be nice to only habe Dutch menu links show up in the Dutch menu. When you can have a Dutch menu link but link it to a English translation, this will allow for more flexibility.

#2144377: Entity reference autocomplete lists entity labels only in current content language - The entity_autocomplete form shows available entity titles in the translation of the current interface language. This doesn't mean you will actually get a link to that specific translation. It would help to explicitly choose the preferred language of the destination.

Proposed resolution

Allow a preferred language for link fields.

Remaining tasks

User interface changes

Optionally added select list for 'Preferred language' to link fields.

API changes

None

Data model changes

None

When content language detection is different from interface language detection, the detected language is not applied to the rendered content

$
0
0

Problem

When setting language detection method, the checkbox Customize Content language detection to differ from User interface text language detection settings is not applied, only the interface configuration.

This leads to two critical issues with translating content:

  1. It is not possible to edit translated version of a node. All "Edit" urls on node's "Translate" tab are the same and lead to main editing form. See edit.png.
  2. Translated content is never shown to the user. Default language is always displayed.

Steps to reproduce

On a fresh D8 install:

  1. Enable content translation and language modules
  2. Add another language
  3. Set Detection and selection method to session and browser (tested both, both are broken)
  4. Configure content type "Article" to be translatable (Administration >> Configuration >> Regional and language)
  5. Add a node and set it's language to default one (I used article with image. All fields were filled including image)
  6. Translate node to a second language and save.
  7. Go to "Translate" tab and investigate "Edit" links. Both lead to the same page.
  8. Go to the newly create node and try switching language using "session" parameter. You will still see the node in default language.
  9. Do the same with a browser running second language (or just spoof the browser string to change language). You will still see the node in default language.

Remaining tasks

  1. Investigate why the checkbox Customize Content language detection to differ from User interface text language detection settings is ignored. The source of the issue lies probably inside Drupal\language\Form\NegotiationConfigureForm::submitForm() function. - the configuration is correctly saved
  2. Create patch - Patch is provided

User interface changes

No changes to the UI are required for the fix.

API changes

The protected variable type which indicates whether a given type of language usage (language_content, language_interface, language_url) changes to an array to allow different types to initialize during the initialization of another.

Entity Autocomplete database leak

$
0
0

Lately, in one of our prod database, the key_value table became 2.4GB large.
When I took a closer look I could see that there are around 200 000 records in it, and 90% of them are entity_autocomplete collection. Then I searched the entity reference module where does it operate with the keyValue service and I found the following:

    // \Drupal\Core\Entity\Element\EntityAutocomplete:129
       $selection_settings = isset($element['#selection_settings']) ? $element['#selection_settings'] : [];
        $data = serialize($selection_settings) . $element['#target_type'] . $element['#selection_handler'];
        $selection_settings_key = Crypt::hmacBase64($data, Settings::getHashSalt());
    
        $key_value_storage = \Drupal::keyValue('entity_autocomplete');
        if (!$key_value_storage->has($selection_settings_key)) {
          $key_value_storage->set($selection_settings_key, $selection_settings);
        }

The $selection_settingsmay contain the host entity as well (it's self reference feature). This means based on the code: whenever you have a new entity or the entity updated your $selection_settings_key will always be different. Also it's added to the key-value table without expiration date which will end up as a permanent out of date record (after the entity changed / field config anyhow) in your key-value table. Also because it's serializing the whole entity the record itself can be quite big (talking about 10-12 KB).

Is this a bug or am I missing something?

Migrate upgrade shows errors in green

$
0
0

Problem/Motivation

After running a migration via the UI some helpful information is displayed but that include the message '8 upgrades failed' in green which surely should be in red. Or am I mistaken?

Proposed resolution

Display the failure in red

Remaining tasks

Write a patch
review
commit

User interface changes

Errors will be displayed in red not green.

Missing url prefix on language neutral content

$
0
0

What are the steps required to reproduce the bug?

  • Install a new Drupal instance
  • Add an additional language (e.g. italian)
  • Use URL negotiation and configure path prefixes (e.g. /en for english and /it for italian)
  • Enable the language selector for content type
  • Create new node using "not specified" as language
  • Go to /it/admin/content

What behavior were you expecting?

The main link to the entity inside the content table should link to /it/node/1 (the current user interface language based on the url /it/admin/content).

What happened instead?

The main link to the entity inside the content table links to /node/1, which changes the site language (based on language path prefix) back to english.


I added a simple patch, but I'm not sure about consequences outside the described use-case.
The $entity->toURL() method adds the entities current language as an URL option to the link generator. The provided patch applies the current language as a prefix base if the nodes language is "not specified".

Password reset form reveals whether an email or username is in use

$
0
0

Problem/Motivation

We want to avoid that everybody can check if an email is already registered on a Drupal site. So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not. Therefore the displayed message must be changed.

On 'Request new password' form (/user/password), you get the following message if you enter a unused mail address or username:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get:

Further instructions have been sent to your e-mail address.

So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not.

I think this can be a privacy issue. Think of the following scenario:
Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Proposed resolution

never print "Sorry, XYZ is not recognized as a user name or an e-mail address.",
always print "Further instructions have been sent to your e-mail address.".

Maybe we should change the wording of this message then (adding something like "if matched any account").

Remaining tasks

Check that the items in the following list have already been done.

See the comment in #101 for the remaining changes needed.

Contributor tasks needed
TaskNovice task?Contributor instructionsComplete?
Create a patchInstructionsComplete
Reroll the patch if it no longer applies.InstructionsComplete
Add automated testsInstructionsComplete
Manually test the patch NoviceInstructions
Embed before and after screenshots in the issue summary NoviceInstructions

User interface changes

On 'Request new password' form the status message if an email is already registered is going to be changed:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get the following message that should be changed also:

Further instructions have been sent to your e-mail address.

API changes

None

Original report by no2e

(coming from #1359718: Allow password reset on account w username matching another email. Prevent registrations which match another account)


On 'Request new password' form (/user/password), you get the following message if you enter a unused mail address or username:

Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.

If you enter a used mail address or username, you get:

Further instructions have been sent to your e-mail address.

So, an anonymous user can easily check whether there is a user registered with a certain e-mail-address or not.

I think this can be a privacy issue. Think of the following scenario:
Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Possible solution:
never print "Sorry, XYZ is not recognized as a user name or an e-mail address.",
always print "Further instructions have been sent to your e-mail address.".

Maybe we should change the wording of this message then (adding something like "if matched any account").

Steps to reproduce this issue

  • Install the latest Drupal 8.x version
  • log in and create a new user with a username and email
  • log out
  • go to the following page: user/password
  • enter a name or email of an invalid user
  • if the latest patch is not applied the following message appears: Sorry, john.doe@example.com is not recognized as a user name or an e-mail address.
  • then enter the name or email of the new user you just created
  • if the latest patch is not applied the following message should appear: Further instructions have been sent to your e-mail address.
  • apply the latest patch
  • run update.php
  • when entering a valid or invalid username or email just the following message should always appear: Further instructions have been sent to your e-mail address.
  • so, now there is only one message displayed and it is not possible any more to check if an email is registered or not

Table forum_index needs a primary key to work on Percona

$
0
0

Problem/Motivation

On an environment running on Percona as the database backend, we get an error of the following form when creating a new forum topic:

{{General error: 1105 Percona-XtraDB-Cluster prohibits use of [error]
DML command on a table ([redacted].forum_index) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER: INSERT
INTO
{forum_index}
(nid, title, tid, sticky, created, comment_count, last_comment_timestamp) VALUES (:db_insert_placeholder_0,
:db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4,
:db_insert_placeholder_5, :db_insert_placeholder_6); Array
(
[:db_insert_placeholder_0] => 96349
[:db_insert_placeholder_1] => [redacted]
[:db_insert_placeholder_2] => 5314
[:db_insert_placeholder_3] => 0
[:db_insert_placeholder_4] => 1366366923
[:db_insert_placeholder_5] => 0
[:db_insert_placeholder_6] => 1366366923
)}}

Proposed resolution

Add a primary key for nid, tid (tid needs to be included because creating a shadow topic will create an extra entry for the same nid, with a different tid).

Remaining tasks

Create patch
Review
Commit

User interface changes

None.

API changes

None.

Data model changes

Primary key [nid,tid] on the forum_index table.

Error when saving settings of an entity reference field

$
0
0

Problem/Motivation

When saving the settings of an entity reference field (in my case an image field) using the field_ui module I'm getting the following error:

Error: Call to a member function uuid() on null in Drupal\Core\Field\EntityReferenceFieldItemList->defaultValuesFormSubmit() (line 126 of /var/www/html/web/core/lib/Drupal/Core/Field/EntityReferenceFieldItemList.php) 
#0 /var/www/html/web/core/modules/field_ui/src/Form/FieldConfigEditForm.php(167): Drupal\Core\Field\EntityReferenceFieldItemList->defaultValuesFormSubmit(Array, Array, Object(Drupal\Core\Form\FormState)) #1 [internal function]: Drupal\field_ui\Form\FieldConfigEditForm->submitForm(Array, Object(Drupal\Core\Form\FormState)) 
#2 /var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php(111): call_user_func_array(Array, Array) 
#3 /var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php(51): Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object(Drupal\Core\Form\FormState)) 
#4 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(585): Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object(Drupal\Core\Form\FormState)) 
#5 /var/www/html/web/core/lib/Drupal/Core/Form/FormBuilder.php(314): Drupal\Core\Form\FormBuilder->processForm('field_config_ed...', Array, Object(Drupal\Core\Form\FormState)) 
#6 /var/www/html/web/core/lib/Drupal/Core/Controller/FormController.php(74): Drupal\Core\Form\FormBuilder->buildForm('field_config_ed...', Object(Drupal\Core\Form\FormState)) 
#7 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch)) 
#8 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) 
#9 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() 
#10 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) 
#11 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) 
#12 [internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() 
#13 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(144): call_user_func_array(Object(Closure), Array) 
#14 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) 
#15 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#16 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#17 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#18 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#19 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#20 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#21 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#22 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(652): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) 
#23 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) 
#24 {main}.

I have not been able to track down what is causing this problem, though I have found what solves it (for me).

EntityReferenceFieldItemList::defaultValuesFormSubmit returns an array with an empty item which then will be loaded as an entity, which obviously has no uuid.

Proposed resolution

Filter out empty array items using array_filter().

Remaining tasks

  • Find out what is causing the problem
  • Solve the problem

User interface changes

None.

API changes

None.

Data model changes

None.

Add a DataType normalizer for layout_section

$
0
0

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections appear empty.

Proposed resolution

We should add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

Write a patch, possibly discuss what setting (unserializing) sections looks like via an API like REST.

User interface changes

None.

API changes

A new normalizer will be added for the layout_section DataType.

Data model changes

None.

"Unfiltered Text" header/footer stripping iframes

$
0
0

Views "unfiltered text" headers/footers strip iframes prior to rendering the text. This goes contrary to the description which reads "Add unrestricted, custom text or markup. This is similar to the custom text field." Users currently must use the "text area" header/footer -- with a formatter that doesn't limit HTML tags -- if they want to include an iframe.

Expected behavior is either:
-- Users should be able to input an iframe into an "unfiltered text" header/footer
-- The descriptive text should be updated to reflect that iframes are not allowed.

Migration tables (ID map etc.) don't get removed

$
0
0

After uninstall migration modules the tables created not removed and still exist and can not be reasonable to deploy without remove that tables.

Problem:
The 3 modules Migrate, Migrate_drupal, Migrate_drupal_ui didn't implement Hook_uninstall() to remove these tables or other data related to migration and have no use after complete migration.

Motivation:
List all tables prefixed with migrate_ in hook_install.
Implement hook_uninstall to remove all tables prefixed with migrate_ except those listed when install the same prefix.

Solution
The migrate core module must list all tables prefixed with migrate_ during installl.
The migrate module must remove all tables prefixed with migrate_ during uninstall.

Kindly reveal the wrong suppositions I made here and the best practice to achieve.

Viewing all 298635 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>