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

Entity::uriRelationships() throws exceptions if an URL cannot be generated because of missing mandatory parameters

$
0
0

Problem/Motivation

If there is a link template with mandatory parameters the url cannot be generated without providing those parameters. If we try to build the url without the mandatory parameters the exception Symfony\Component\Routing\Exception\MissingMandatoryParametersException will be thrown.

The entity predelete hook menu_link_content_entity_predelete introduced in #2350797: Orphaned menu links when nodes are deleted if menu_link_ui is not enabled is the one that introduced the problem by calling \Drupal\Core\Entity\EntityInterface::uriRelationships().

This might occur if the diff module is used and a link template like this is added:
"revisions-diff" = "/custom_entity/{custom_entity}/revision/{left_revision}/{right_revision}/{filter}"

This is a major as it prevents deleting entities having such link templates and there is no workaround for this.

Proposed resolution

\Drupal\Core\Entity\EntityInterface::uriRelationships() should catch exceptions of the type MissingMandatoryParametersException.

Remaining tasks

User interface changes

API changes

Data model changes


Update Layout Builder CSS to match updated mockups

Button 'Remove' is not working in Quick Edit for media type field with Video

$
0
0

Was created for Article media type field, where video was uploaded. After clicking Quick Edit link and video area we see dialog for removing video file. So button 'Remove' is not working. After clicking nothing happens.
Video remove button not working

Steps:
1)Please, activate module 'media' (machine name).
2)Please, add field Media reference field for article(/admin/structure/types/manage/article/fields).P.S. In tab REFERENCE TYPE please select checkbox 'Video' for 'Media type'.
3)On /media/add/video add content type of Video.
4)On /node/add/article create node: content type of Article with field of Media reference to 3).
5)Try to edit node from 4) after consistent clicking 'Quick edit' and clicking to Video area.

Add save dropbutton next to 'Back to content editing' link in node preview.

$
0
0

Problem/Motivation

As @webchick said in #1510544-126: Allow to preview content in an actual live environment

I found my natural inclination while testing this was to want to be able to save right when I'm looking at the page

Follow-up of #1510544: Allow to preview content in an actual live environment

Proposed resolution

Add save dropbutton as per #1751606: Move published status checkbox next to "Save" to the preview bar.

Remaining tasks

  1. Postpone on #1510544: Allow to preview content in an actual live environment and #1751606: Move published status checkbox next to "Save".
  2. Add save dropbutton.

User interface changes

We'll have a save dropbutton next to "Back to content editing" link.

API changes

None

save button.png

Submitting a comment in the non default language redirects you to the default language

$
0
0

Problem/Motivation

In a multilingual site if you add a comment on a node which is in the default language, everything is okay.
But if you add a comment on a node which is not in the default language, I get redirected to the default language translation of the node.

This is very confusing for the end user and they should stay in the same node language after submitting a comment.

This is very easy to replicate on simplytest.me (choose multilingual setup).

Proposed resolution

Redirect the user to the node translation where the comment is made.

Remaining tasks

Do the patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Remove the drupal.sh script

$
0
0

Problem/Motivation

The drupal.sh script, which executes a Drupal page from the shell, is rarely used.

Proposed resolution

There are three proposed resolutions.
1. Remove drupal.sh from the project, and rely on contrib or other tools to provide this functionality. [(IMPLEMENTED in patch #19) Waiting on @chx and @David_Rothstein to respond related to this as per @webchick 's comment #21]
2. Rewrite this functionality using Symfony's method of doing the same task. [POSTPONED depending on completing remaining tasks below.]
3. Leave the drupal.sh script as is.

Remaining tasks

1. Determine which resolution is the correct task.
2. Implement that resolution.

Original report by @cosmicdreams

Does anyone use drupal.sh? The scripts claims that you can mock a http request with the script but that job is better handled by Drush these days.

This script seems like it is unnecessarily bundled with core and probably should be removed now.

Thoughts?

SQLSTATE[40001]: Serialization failure: 1213 Deadlock

$
0
0

Hi All,

I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.

Here is more detail about site configuration on server :-

The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.

So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)

I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) 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) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:

After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.

Have not been able to find any reliable solution for this.

Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?

Any suggestions would be appreciated.

Thanks
Atul

Firefox drupal login form causing flash of unstyled content

$
0
0

Firefox loads JS before CSS, causing flash of unstyled content. On IE and chrome I don't have this issue.
First I thought it was an issue with my theme but it also happens with bartik on a clean install.

I think the cause is that firefox loads JS before CSS.

This issue only happens on the user login and reset password pages. (user/login and user/password)


Sample code needs to have namespace on the Url class.

Prevent memory leak and inconsistent entity references when serializing entity storages

$
0
0

Problem/Motivation

I've recently encountered a place where the entity storage has been kept as property on the entity class. If the entity type doesn't support static cache then everything is fine, but if it doesn't then this might lead to a memory leak on each entity load, as then the the entity is written to the persistent cache and when a lot of entities are being loaded the serialized storage will get bigger and bigger and so each serialized entity.

Proposed resolution

We could prevent this automatically and there are the two options:
In EntityStorageBase::__sleep() don't return the property for the static entity cache.
In DependencySerializationTrait::__sleep() and ::__wakeup() take care of entity storages kind of like taking care of service objects.

The first option feels like the more natural to do, as the static cache is part of the entity storage, but on the other side there is no point to serialize the storage object as this takes more memory and actually having different storage instances for the same entity type around might break things as well, therefore not serializing it should be the better option as this could prevent other bugs beside memory leaks.

Remaining tasks

User interface changes

API changes

Data model changes

8.5.0 resources issue

$
0
0

I recently upgraded from 8.3.7 to 8.5.0. I had some significant issues getting everything upgraded and working properly, but everything seems fine now except for one major issue. Since the upgrade, I have noticed my server is running out of memory and database connections are not closing. I host on AWS and have an auto scaling group, so I don't experience much downtime, but sometimes I do have to restart the RDS instance. I did not experience anything like this on 8.3.7. I posted on reddit and it seems someone else has noticed this same issue. They ended up having to revert back to their previous version for their server to run properly. I run our install on 2 servers behind a load balancer.

Our servers are dual core with 8gb of ram, so they are pretty robust and I can't imagine not being able to run Drupal off of this setup. The memory allocation starts failing, then the CPU spikes pretty high, and the DB connections stay open. I know this won't be fixed in 8.5.1 since it is just a security update. I searched the issues, but I was unable to find anything. Anyone else notice this issue or if someone else has reported it? Thanks.

Set printerClass in phpunit.xml.dist

$
0
0

Follow-up to #2811065: Fix docs around --printer option in phpunit.xml.dist

Problem/Motivation

From #2811065-12: Fix docs around --printer option in phpunit.xml.dist

AFAICT, the printerClass definition works, and does not break PHPStorm any more. 2016.3 EAP, October 19, 2016.

Proposed resolution

https://youtrack.jetbrains.com/issue/WI-24808 is resolved so add the printerClass to phpunit.xml.dist

Remaining tasks

  • Verify it.
  • RTBC if fixed.
  • Report a jetbrains bug if not fixed.

User interface changes

None

API changes

None

Data model changes

None

Bring migrate_source_csv to core

$
0
0

In #2809635: Create experimental installation profile, we are using CSV files to provide default content for a demo installation profile of Drupal.

In a review, @larowlan suggested bringing the CSV migration sources into core:
https://www.drupal.org/project/drupal/issues/2809635#comment-12381619

I agree that a CSV migrate source would be a very useful feature for core.

The migrate_source_csv module has a stable release (2.0), has been downloaded almost 100k times (not sure if that includes composer stats?), and comes complete with tests. The contenta CMS has been using this for their migrations, too.

So would it be ok to look at moving this into Core's migrate module? If so, I'm happy to try and turn the module into a patch.

"How to install curl" links in codebase are not helpful

$
0
0

To reproduce:
I run update.php, which tells me CURL is not found. It links me to https://www.drupal.org/requirements/php/curl

That link takes me to a page which has installation instructions for PHP5 rather than PHP7. Scrolling to the top of the page says it’s for Drupal 7, with a link to take me to Drupal 8 instructions (https://www.drupal.org/docs/8/system-requirements/drupal-8-php-requirements)

But that link goes to a 404.

Issue summary:
1) update.php link for Drupal 8 goes to a Drupal 7 related page
2) The link on said D7 page for D8 takes you to a page that doesn't exist.

composer fail to upgrade from 8.4.4 to 8.5.0-alpha1

$
0
0

composer fail to upgrade from 8.4.4 to 8.5.0-alpha1


When deleting an entity, references to the deleted entity remain in entity reference fields

$
0
0

What are the steps required to reproduce the bug?

Given a content type with an entity reference field...
1. create node A and node B
2. create node C, that references node A and node B (in that order)
3. delete node A
4. node C still has a reference to node A in DB, and you'll see an empty spot above the reference to node B where the reference to node A used to be

What behavior were you expecting?

Any references to node A would be removed once node A is deleted.

What happened instead?

Node C still has a reference to node A, even though node A no longer exists.

SessionManager improperly abstracts Symfony's Session Component

$
0
0

Problem/Motivation

The upgrade to Symfony 3.4 introduced the use of the SessionProxyBag for any bags within the session system. (Found in this commit, Thanks to Tim Plunkett): https://github.com/symfony/http-foundation/commit/d9625c8abb907e0ca2d750...

Our usage of the SessionManager often results in code like this:


$this->sessionManager->getBag('attributes')->set('foo', 'bar');

This would have been fine and worked in 8.4.x and earlier, but in 8.5 you must now:


$this->sessionManager->getBag('attributes')->getBag()->set('foo', 'bar');

This is because getBag('attributes') used to return an AttributesBag and now returns a SessionProxyBag which wraps the AttributesBag. This is super confusing for a number of reasons, but most importantly, our session handling appears to be a strange "Drupalism" of an abstraction around most of the components Symfony provides without directly using the paradigm they expect. I've not dug in enough to know all the nuance on this, but this was definitely an API break for us because of HOW we use it. Also, worth pointing out that the expected return values make both sets of code above completely unsafe without a ton of additional type checking.

Proposed resolution

We might want to look at how we handle sessions in general and come up with a longer term solution, but for the foreseeable future, we should probably change the getBag() implementation on SessionManager today to identify when we're dealing with a SessionProxyBag and return the bag it's wrapping. This would have completely prevented me from running into this problem. (Again, thanks to Tim for the suggested fix there).

Remaining tasks

Determine appropriate course of action.

User interface changes

None

API changes

This would actually return the API to what it was in 8.4.x, so I consider the current state an api break.

Data model changes

N/A

User roles missing in /user/login?_format=json REST response

$
0
0

Problem/Motivation

User roles missing in /user/login?_format=json REST response.

Super admin login response is mentioned below.

{
	"current_user": {
		"uid": "1",
		"roles": [
			"authenticated",
			"administrator"
		],
		"name": "admin"
	},
	"csrf_token": "SMr4VPJU-2pr3vTOxTNdt-L2pqr6vUzNDePQfVDixGM",
	"logout_token": "3HJ-Wzdf_5aX6GTDOjHrBq4OEcVijPk2Ggnpvfi3lGk"
}

If a user try to login via REST resource /user/login?_format=json

{
	"current_user": {
		"uid": "32",
		"name": "sumeshsr110"
	},
	"csrf_token": "T6eQNBEl9ec9XelondCKV8AXaEd8IQ1mKcE0-289aho",
	"logout_token": "cl0z652AK4wpVcdbA4YU05neftpfZiZqgCKCD8hjdNg"
}

I have checked the REST resource. ( core/modules/user/src/Controller/UserAuthenticationController.php ). It has one checking, see the below code.

      if ($user->get('roles')->access('view', $user)) {
        $response_data['current_user']['roles'] = $user->getRoles();
      }

How can I get the user roles for all type of users via successful REST login ?

Views Counter variable only equal to zero with Twig

$
0
0

I created a view. I added the global counter variable field. On a field below the counter field I chose to rewrite the output. In this rewritten field, if I output the counter field using {{ counter }} I get the value I would expect. That is, I get an incremental number starting at 1 for each row in the view. When I try to use Twig in the rewrite field though to test if the counter value is greater than a certain number, like {% if counter > 1 %} for example, it does not work. After several testing, it appears that the counter is always equal to zero when testing it in a Twig if statement, even though it outputs an incremental number each time.

cURL calls are taking more than 5 seconds, causing simpletest failures

$
0
0

When a simpletest test makes an HTTP request, like drupalGet(), the assumption is that drupal_valid_test_ua() will pick up the database prefix out of the user agent string that cURL assigns, and so use the correct test environment. But drupal_valid_test_ua() will reject an agent with a timestamp component that is 5 seconds or more in the past. If the cURL call takes more than 5 seconds to run, no test prefix will be used, and the result can be random failure or other unexpected behavior.

For instance, I noticed this because I'm running a Docker based virtual installation for local development. We are using HTTPS for testing because that's how the real system will run. It was taking about 10 seconds for the first curl_exec() call to make the HTTPS connection. In my case this resulted in a 404, because the test module had only been enabled in the test environment (the tables using the simpletest prefix string). Subsequent curl_exec() calls reuse the existing connection and so run within the 5 second time window.

Viewing all 293406 articles
Browse latest View live


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