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

Domain URL language detection - InvalidArgumentException: The user-entered string must begin with a '/', '?', or '#'

December 8, 2018, 1:09 am
$
0
0

On a fresh Drupal 8.6.4 installation, Domain URL language detection not working on some pages. For example when trying to access /admin/structure/block after the domain configuration was saved, this error shows up:
InvalidArgumentException: The user-entered string 'https://........./web/admin/structure/block' must begin with a '/', '?', or '#'. in Drupal\Core\Url::fromUserInput() (line 204 of /home/testing1/web/core/lib/Drupal/Core/Url.php).

This can be reproduced very easy following these steps:

1. Add second language
2. Go to Configuration > Regional and language > Languages > Detection, click on Domain and save the configuration.
3. Clear caches, run cron.
4. Visit /admin/structure/block

Thanks.

↧
Search

Make the output of final exception subscriber developer friendly

April 25, 2017, 1:04 am
$
0
0

The exception response has been turned into text/plain last year for the purpose of security (SA-CORE-2016-004). For this reason HTML entities are now shown unprocessed. I propose we strip out HTML tags and decode special chars to make the error messages more readable.

Before:

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">LogicException</em>: The controller must return a response (null given). Did you forget to add a return statement somewhere in your controller? in <em class="placeholder">Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw()</em> (line <em class="placeholder">171</em> of <em class="placeholder">vendor/symfony/http-kernel/HttpKernel.php</em>). <pre class="backtrace">Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

After:

The website encountered an unexpected error. Please try again later.

LogicException: The controller must return a response (null given). Did you forget to add a return statement somewhere in your controller? in Symfony\Component\HttpKernel\HttpKernel->handleRaw() (line 171 of vendor/symfony/http-kernel/HttpKernel.php).

Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
↧
↧

composer require is a slow and cumbersome way to add modules

February 15, 2018, 5:50 am
$
0
0

"composer require" may offer many benefits but in terms of adding modules easily and quickly without interrupting workflow it is a huge step back from "drush dl".

are there any ways to optimize to restore some of the convenience of a single command and a few seconds wait?

thanks

↧

Available states determined incorrectly for new content translations

December 18, 2018, 6:43 am
$
0
0

How to reproduce:
1. install drupal-8.7-dev, standard profile
2. enable workflows, content_moderation, language, content_translation
3. add Spanish language
4. enable translation for article content
5. replace workflow transitions with: draft->draft, draft->published, published->archived
6. attach article content type to workflow
7. create new English article, save as draft
8. edit article and save in published state
9. translate article to Spanish and open list of available moderation states

Expected result:
The draft and published states should be available.

Actual result:
Only the archived state is available.

Notes:
I have reduced the repro case as much as possible, as is customary. The actual workflow which tripped on this bug is much more complicated, with states from which it is reasonable to block transitioning back to the draft state (in contrast with this trivial example). When the original language version for a content item lands in such a state, states which should be available for new translations of that content item are unavailable. The software is determining the available initial states for a new translation based on the current state of the original language version of the content item, which is not appropriate.

This is related to https://www.drupal.org/project/drupal/issues/2927455, but is not a duplicate of that issue, which only reports that the default state of the translated content is incorrect. This issue is more serious, in that now states which should be available for new translations are not available at all for selection, and not just not the default.

OS: Linux (Ubuntu 18.04.1 LTS)
Web Server: apache 2.4.29
PHP: 7.2.10

↧

Deprecate render() function in common.inc

September 2, 2016, 5:38 am
$
0
0

Problem/Motivation

render() is no longer called very often, in fact Drupal core only calls it 4 times. The problem with that function is that in certain circumstances, i.e. when using Drush or DrupalConsole, there is no render context and that throws exceptions.

I was hit by that the second time today where a contrib developer unintentionally used that function which was perfectly right but with Drush I got errors all over the place.

A better replacement would be \Drupal::service('renderer')->renderPlain($renderArray); or maybe render could be rewritten to call exactly that?

My concern is that contrib developers not being aware of the problem could introduce more usages of that function causing trouble some time down the road.

Proposed resolution

Mark render() as deprecated in Drupal 8.3.x for removal before 9.0.0 release.

Remaining tasks

Once the deprecation status has been set, file a follow-up issue to remove usages, and an issue to remove the function for D9.

User interface changes

API changes

Data model changes

↧
↧

Migrating D7 body and summary fields to D8

November 4, 2018, 9:41 pm
$
0
0

What is the correct way to migrate Drupal 7 body fields (or other Drupal 7 long text with summary fields) to Drupal 8?

For a regular D7 content type being migrated to a D8 content type, for the body, I have tried:

body: body

and

'body/value':'body/value''body/summary':'body/summary'

and 

body:
  plugin: sub_process
  source: body
  process:
    value: value
    summary: summary

None of these seem to work.

I also need to migrate body format, but wanted to get summary working first, so it is not in my examples above.

Thanks for you help!

↧

Optimize getCommentedEntity()

October 5, 2015, 11:13 am
$
0
0

Click on the right hand side of https://www.dropbox.com/s/dqc7duebdzzr88d/result-node1-no-page-cache-fla... in the bar called Drupal\comment\CommentLazyBuilders::renderLinks. There you will see a wide bar for getCommentedEntity(). This method can be optimized to pull right from persistent entity cache if available.

Incidentally, I notice that buildLinks() calls $entity->getCommentedEntityTypeId() and $entity->getCommentedEntityId() despite having been passed in the commented entity.

Why this issue should be an rc target

This change will enable a significant performance improvement. @todo What are the potential disruptions, if any?FIxed test :)

↧

Ensure that aliased/used backend overridable are not set to private

December 18, 2018, 11:20 am
↧
Search

Broken/missing handler on bulk action field in Media Library view

September 25, 2018, 7:30 am
$
0
0

I'm working with a couple of dozen Drupal 8 sites, and I'm experimenting with Media Library. What I've found is that on the new sites I build with 8.6, Media Library works like a champ. On older sites that I built in 8.4 or 8.5, and have upgraded to 8.6, the media_bulk_form field in the view has a "Broken/missing handler" error.

Poking around the database, I found that these four actions didn't exist in the config for the older sites:

system.action.media_delete_action
system.action.media_publish_action
system.action.media_save_action
system.action.media_unpublish_action

Exporting them from a newer site and importing them into the older sites appears to fix the problem. Should these be installed automatically with the Media Library module?

↧
↧

The getDefaultSectionStorage() method on OverridesSectionStorage does not return the correct object

December 27, 2018, 3:53 pm
$
0
0

OverridesSectionStorage has a method getDefaultSectionStorage, which (according to the interface OverrideSectionStorageInterface should return an object that implements \Drupal\layout_builder\DefaultsSectionStorageInterface. However, it's currently returning an \Drupal\Core\Entity\Display\EntityViewDisplayInterface.

I believe the docblock on the interface is correct, but the implementation is wrong.

↧

Create "file upload" service that core REST, JSON API and GraphQL can all use

January 29, 2018, 8:42 am
$
0
0

Problem/Motivation

… but first we need input from JSON API and GraphQL on which parts make sense to reuse. Then we need to find consensus.

We'll be able to refactor the REST module's @RestResource=file_upload plugin in any case, because none of its behaviors will change, only implementation details will change (they'll be extracted into a separate service).

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

None.

API changes

None — only API additions.

Data model changes

None.

↧

\Drupal\Core\Url does not accept root-relative (file) URLs, making it impossible to let LinkGenerator create root-relative file URL links

January 8, 2016, 5:53 am
$
0
0

Problem/Motivation

Examples:

  • template_preprocess_file_link()
  • \Drupal\file\Plugin\Field\FieldFormatter\BaseFieldFileFormatterBase::viewElements()
  • \Drupal\file\Plugin\Field\FieldFormatter\FileUriFormatter::viewValue()
  • …

These all generate links (<a href="…"></a>) using LinkGenerator/\Drupal\Core\Link, which in turn require \Drupal\Core\Url objects.

Those \Drupal\Core\Url objects require a URL scheme. Which means root-relative (file) URLs cannot be passed to them, which means we must generate absolute file URLs, which means trouble as soon as you encounter sites available over both HTTP and HTTPS.

Proposed resolution

Detect root-relative URLs, automatically use the base: scheme. This is then similar to what \Drupal\Core\Url::fromUri() already does for protocol-relative URLs.

Remaining tasks

None.

User interface changes

None.

API changes

No changes; one addition: Url::fromUri() no longer considers /cat.png invalid (i.e. as using an invalid URI scheme); instead it detects this as a root-relative URL and hence uses the base: scheme.

Data model changes

None.

↧

Node revisions tab have "Current Version" on every Page

December 19, 2018, 11:11 pm
$
0
0

Node revisions tab have "Current Version" on every Page

Problem

  • Create a Page.
  • Add revisions.
  • Check the Revisions tab with page 1 to other paginations

Page
Page 2

↧
↧

PhpUnit make test results more developer friendly

March 2, 2017, 10:07 am
$
0
0

One thing I am always missing when running tests through command line is finding HTML output file by URL of HTTP request logged in it. I propose adding a meaningful label above each reference on HTML output file (see attached screenshots).

↧

block_content block derivatives do not scale to thousands of block_content entities

January 30, 2018, 12:45 pm
$
0
0

Problem/Motivation

A request that immediately follows a cache rebuild or a memcached flush results in a major performance issue, as Drupal tries to cache all available blocks at once. We ran into an issue on a couple of applications where memcached didn't have enough memory allocated to withstand the onslaught of memcache_set. This resulted in multiple calls for all of the blocks to be set en masse in memcached - because it attempts to fulfill its initial request ("write ~2300 blocks to cache_discovery, please"), then runs out of room (hits the memory ceiling), then tries to complete the job by taking a second swipe at it. You can see this at work in this xhprof run:

xhprof

MemcachePool_set is being called over 4600 times here - which is approximately 2X the number of custom blocks in the database:

mysql> SELECT COUNT(*) FROM block_content;
+----------+
| COUNT(*) |
+----------+
|     2294 |
+----------+
1 row in set (0.00 sec)

Proposed resolution

Skip the entity api completely and go directly to the tables for the required data. The entirety of the required data for the current deriver is contained in block_content and block_content_field_revision. A single simple join is much faster and more performant for sites with heavy custom block usage.

Remaining tasks

Validate the approach in the patch and update as necessary.

User interface changes

None

API changes

None

Data model changes

None

↧
Search

Add hook_field_schema_alter()

January 21, 2010, 1:02 pm
$
0
0

In #502522: Allow drupal_alter() on the various Field API declarative hooks we deferred hook_field_schema_alter() to a follow-up issue, but then never opened the follow-up issue. I still think we need it - for optimizing queries both in default SQL storage, and in non-SQL storage.

Barry's argument on that issue was that we don't have hook_field_schema_alter() because there's no hook_schema_alter() - except that we do: http://api.drupal.org/api/function/hook_schema_alter/6

For the reasons we have hook_schema_alter() - mainly site-specific tweaks, we should allow the same for field storage.

↧

Memory requirement >2G for composer installation

December 16, 2018, 3:45 pm
$
0
0

I am trying to install D8 with composer (using drupal-composer/drupal-project) on SiteGround (max 1G memory) and A2Hosting (max 2G memory) and am getting memory errors, as per example below:

santisch@nl1-ls3 [~/public_html]# composer create-project drupal-composer/drupal-project:8.x-dev d_test4 --stability dev --no-interaction
Installing drupal-composer/drupal-project (8.x-dev c1e2b6e6b32d51e75321d76c503714d8515e2420)
  - Installing drupal-composer/drupal-project (8.x-dev c1e2b6e)
    Cloning c1e2b6e6b32d51e75321d76c503714d8515e2420

Created project in d_test4
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing cweagans/composer-patches (1.6.5)
    Loading from cache

  - Installing composer/installers (v1.6.0)
    Loading from cache

  - Installing composer/semver (1.4.2)
    Loading from cache

  - Installing drupal-composer/drupal-scaffold (2.5.4)
    Loading from cache

...

  - Installing doctrine/common (v2.10.0)
    Loading from cache

  - Installing asm89/stack-cors (1.2.0)
    Loading from cache

  - Installing drupal/core (8.6.4)
    Downloading: 25%          
Fatal error: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 6291488 bytes) in phar:///opt/cpanel/composer/bin/composer/src/Composer/Util/RemoteFilesystem.php on line 280

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.santisch@nl1-ls3

I was able to install earlier versions of D8 with composer on A2Hosting. It appears that Drupal/core is (too) large now. On SiteGround I am currently stuck with D 8.3 and an old composer installation.

Can anybody confirm that >2G memory is required for newer D8 installations? Are there any workarounds possible to remain within the current hosting plan? Can the core be split up for a less memory intensive installation?

↧
↧

Entity BaseFields of type list_string do not get a select list exposed filter in Views

November 21, 2018, 10:27 am
$
0
0

I have a custom entity, with BaseFieldDefinitions. One of which is a list_string type. When I try to add an exposed filter in Views for this field, it defaults to a textfield instead of a select list.

When I look at my entity's EntityViewsData::getViewsData() method and dump the results, it's listed as simply "string".

argument => string
filter => string

It'd be nice if it used list_string or whatever the name is for the select filter (if I could find that I could probably just alter the ViewsData myself and get going for now, but ideally this should be automated for BaseFields).

↧

/core/modules/statistics/statistics.php These pages use this blocked resource. If Googlebot can't access important resources on your page, the page might be indexed incorrectly.

June 5, 2017, 2:41 am
$
0
0

I have enabled `statistics` module and now the google bot is saying

"Blocked Resources > http://www.tundriyal.com> /core/modules/statistics/statistics.php
These pages use this blocked resource. If Googlebot can't access important resources on your page, the page might be indexed incorrectly."

More information of blocked resource can be found at https://support.google.com/webmasters/answer/6153277

This is blocking my site from getting crawled on search engines (https://www.drupal.org/project/drupal/issues/2883776#comment-12238819).

↧

Remove useless config action.settings.recursion_limit

December 24, 2018, 4:51 pm
$
0
0

Problem/Motivation

Actions module provides configuration action.settings.recursion_limit which is not used by core (except tests and migrations)

Proposed resolution

Remove it and fix tests with some other useful config

Remaining tasks

- Remove config
- Fix tests
- Decide about migrations
- Add update hooks

User interface changes

API changes

Data model changes

Release notes snippet

↧
Viewing all 298612 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>