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

After 8.5.0 upgrade: Unknown column revision.revision_default

$
0
0

Hey folks. Any idea on where to start looking to debug the following? I'm getting this on one of my sites after the 8.5.0 upgrade. I tried disabling all my contrib modules, yet this error still persists.

[Thu Mar 08 09:41:03.880667 2018] [:error] [pid 22584] [client 69.162.124.237:24151] Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.revision_default' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log AS revision_log, revision.revision_default AS revision_default, base.id AS id, base.type AS type, base.uuid AS uuid, CASE base.revision_id WHEN revision.revision_id THEN 1 ELSE 0 END AS isDefaultRevision\nFROM \n{block_content} base\nINNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array\n(\n)\n" at /var/www/drupal8/www.MYSITE.com/public_html/core/lib/Drupal/Core/Database/Connection.php line 686, referer: http://www.MYSITE.com/

Fix up docblock of generated javascript files and add @codingStandardsIgnoreFile

$
0
0

When the javascript files are compiled from the *.es6.js files a comment is added to the top of the page. This is not a docblock and if phpcs checks the file it will always fail.

I have changed the comment block generation to create a standard docblock and also added @codingStandardsIgnoreFile to the top so it will not be checked by phpcs since this is a generated file.

Views does not add reverse relationship data for entity_reference fields not defined in configuration

$
0
0

Problem/Motivation

core_field_views_data() adds both forward and reverse relationship data for entity_reference fields defined in configuration. Same should be done for entity_reference fields NOT defined in configuration, like entity_reference baseFields.

Proposed resolution

Forward relationships for entity_reference baseFields are added in \Drupal\views\EntityViewsData::processViewsDataForEntityReference(), but reverse references cannot be added here as they have to be on different tables than this method can handle. For the same reason, \Drupal\views\EntityViewsData::mapFieldDefinition() is not applicable either. As the cycle at the end of views_views_data() triggers core_field_views_data() but only for fields stored in configuration, I think it would be a good place to start checking to add reverse relationships for entity_reference baseFields (possibly some other extra corner cases might be handled here which I'm unaware of yet).

Remaining tasks

User interface changes

API changes

Data model changes

Missing commits in download and install via composer

$
0
0

Today I came upon an issue with my drupal instance that needed the private tempstore for anonymous users.
After searching the forums I was lucky to found an issue stating that it was something that was commited into the 8.5 branch.
So I thought i was fine, but after not succeeding in using this function I took a look at the code, to find that the commit is not there.
I triple checked if i was at the right version, and compared it to what I saw here:

https://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/TempStore/P...

the patch which is applied to the set function, was on the git repo, but I could not find it in the same file on my project.
I installed a clean version of 8.5.3, which didn't include the patch aswell.

Next I download drupal the real old fashioned way, via:
https://www.drupal.org/project/drupal/releases/8.5.3
https://ftp.drupal.org/files/projects/drupal-8.5.3.zip

Than to look into the package noticing this patch was not included in there.

So to be safe I thought about looking at the git logs and take the commit before the one I found in the issue, being:
https://www.drupal.org/node/2257231

Which introduced amongst other things a small change to the following file:
core/includes/file.inc

But when I looked at that file in the downloaded zip aswell as my composers installed version. Those changes weren't there.

Now either I'm really not looking at this in the right way or there is an issue with a merge/commit somewhere?

Hopefully someone can give me a second opinion on this?

Layout navigation can be easily missed or be confusing

$
0
0

Problem/Motivation

The proposed approach in #2905922: Implementation issue for Layout Builder leverages local tasks to expose layout functionality. This issue is intentionally started from a problem statement, rather than solution.

This is like to create usability issues as:

  • This is an overarching task, users might not expect or note it near the node edit links.
  • It is not homogeneous to the other buttons, which switch the user into an edit page to edit content.
  • It requires nesting of "save" and "cancel" links to be close to the overall action.

Resulting in the following design:
sub tasks exposing layout buttons

We should explore design alternatives that expose it on the page in such a way that its easy to find, distinct from the other "edit actions" and scalable to include the save and cancel functionality.

Proposed resolution

There are several proposed solutions, include them in the comments.

Remaining tasks

  • Explore design directions
  • UX sign-off on the final direction
  • Development

User interface changes

We expect to change the design of the change layout, save layout and cancel layout navigation.

API changes

-

Layout Builder should use the toolbar modes system once it exists.

$
0
0

Problem/Motivation

Local tasks are sub-optimal for Layout Builder's administrative needs.

Proposed resolution

The proposed toolbar modes issue, once adopted, would be a perfect fit for Layout Builder's needs.

Remaining tasks

#2784589: Provide a method for module to specify that their toolbar items should appear in Edit mode
#2877853: Make toolbar items first class menu citizens
And probably other follow ups, plus the code required to do it in this issue.

User interface changes

Move Layout builder buttons into the administrative toolbar in a custom "layout mode" or similar.e

API changes

None.

Data model changes

None.

Show the Revisions tab/page even when only one revision exists.

$
0
0

_node_revision_access() hides the revisions tab if there's only one revision of a node. pwolanin mentioned at Drupalcon that this had been flagged as confusing (not sure who by so this is a bit anecdotal but it doesn't surprise me) - sometimes the tab is there, sometimes it's not. The page works fine if there's only one revision - just lists a single revision, and that way you know that revisions are enabled / that you have access to them etc.

It also saves us a COUNT() query on the node table when viewing nodes.
screenshot_022.png

badly worded @return for getPreferredLangcode()

$
0
0

API page: https://api.drupal.org/api/drupal/core%21modules%21user%21src%21Entity%2...

> If the preferred language is not set or is a language not configured anymore on the site, the site default is returned or an empty string is returned (if $fallback_to_default is FALSE).

This is phased as "If A or B, then C or D, if E".

So, what happens if A? What happens if B? You can't really tell...

Logically, if there no no language configured on the site, then there's no site default to return, so you'd get an empty string. But it takes a fair amount of picking that sentence apart to see that.

This should be rewritten in several sentences, and ideally with bullet points to explain what happens.


badly formatted sample code in docs for Select::orderBy()

Link field: add the ability to have a static anchor text and link title

$
0
0

Using the link field from the contrib module, you can add a static "anchor text" and "link title", so that the user that fills in the field must enter only the URL. In my websites, I use very very much this feature. Unfortunately, it went lost moving link to core.

And, of course, it would be nice if these static texts could have support for tokens...

Example use-cases:

  • A website that needs to store the link of an IOS or Mac OSX application in the App Store would need this feature to assign the "See [appname] in the App Store" (where [appname] is a token) to the anchor text of a link field without having the risk of publishers changing the exposed default value;
  • You might want to set the anchor text of a link to the value of another field of your content type, but for some reason you need the value either as a field value and the anchor text;

In these two use-cases, you would need a static "link title" too if you want to enhance these links' accessibility.

POST /quickedit/metadata returning HTTP 503

$
0
0

After updating Drupal core to 8.3.4, we started noticing HTTP 503's in Chrome network logs for /quickedit/metadata. This was only error'ing on certain pages, and not others.

There are entries in logs like this:

drupal-requests.log:[07/Jul/2017:03:37:38 +0000] <DOMAIN> POST /quickedit/metadata http_code=500 query= uid=11 php_pid=30600 php_time=0.111 queue_wait=0 request_id="v-9f87f144-62c5-11e7-a8d2-06b6ecb7b133" 
php-errors.log:[07-Jul-2017 13:37:38 Australia/Sydney] PHP Fatal error: Call to a member function getPluginId() on null in /mnt/www/html/<DOCROOT>/docroot/core/modules/quickedit/src/MetadataGenerator.php on line 76 request_id="v-9f87f144-62c5-11e7-a8d2-06b6ecb7b133"

The code referred in the log above: https://github.com/drupal/drupal/blob/8.3.x/core/modules/quickedit/src/M...

The previous version of Drupal we were running (8.2.8) did not have this issue.

Layout Builder's Field Blocks do not work with Quick Edit

$
0
0

Problem/Motivation

When Layout Builder and Quick Edit are enabled, it's expected that Entity Fields are still quick-editable when rendered by the Field Block. It appears that the expected data-quickedit-field-id attributes are not being output, and as a result no fields are quick-editable when Layout Builder is enabled.

Proposed resolution

Panelizer has this exact same problem, which was addressed in #2693163: Quick Edit support for fields displayed using the ctools_field block.. We can probably replicate the logic and tests there in Layout Builder without any issues.

Remaining tasks

Write and review a patch.

User interface changes

None.

API changes

\Drupal\layout_builder\Entity\LayoutEntityDisplayInterface::getRuntimeSections() is now a public method.

Data model changes

None.

description for EntityForm::actions() could use rewording

badly formatted sample code in core.api.php for hook_config_import_steps_alter

[PHP 7.2] create_function() is deprecated

$
0
0

Humbly hoping that Drupal 7 will eventually support PHP 7.2, I will be making issues for possible incompatibilities.

create_function()is deprecated in PHP 7.2. Fortunately for us, there is only one create_function() call in whole D7 core.

I will attach a patch for your review. The only call is used as a callback function for one array_map() call. I have moved it to a standard function. This pattern was also followed in the same file.


Figure out use-cases for per-workspace permissions and provide them if needed

$
0
0

Problem/Motivation

@FabianX brought up a point in #2784921-149: Add Workspaces experimental module that not every site needs the per-workspace "bypass entity access" permission:

Per workspace permissions can clutter permissions page a lot (Current CPS site would have 8100 entries in permissions table); potentially can avoid by putting property on workspace entity that it has permissions or move to a follow-up task as it is dangerous anyway.

As a result, the bypass entity access workspace $workspace_id has been removed from the initial core patch, along with the other per-workspace view / edit / delete as optional permissions that were removed earlier in the process.

The current permissions shipping with Workspace are:

  • Administer workspaces
  • Bypass content entity access in own workspace
  • Create a new workspace
  • Delete any workspace
  • Delete own workspace
  • Edit any workspace
  • Edit own workspace
  • View any workspace
  • View own workspace

Proposed resolution

Figure out if we need per-workspace permission and implement them.

Remaining tasks

Discuss and then implement a solution.

User interface changes

Less clutter in the permission UI.

API changes

Some permissions might be configurable.

Data model changes

Nope.

Fix inconsistent indentation between @code - @endcode block in core

$
0
0

This is a follow-up issue to #2975056: broken sample code in deprecation notices for entity.inc functions. While working on that issue it is noticed that we have the inconsistent indentation between @code - @endcode blocks. At some places, the code is indented with 2 spaces but in other places, it is not. Indent code with 2 spaces.

For example:

This

* @code
* $settings['extension_discovery_scan_tests'] = TRUE;
* @endcode

Should be this:

* @code
*   $settings['extension_discovery_scan_tests'] = TRUE;
* @endcode

Discuss workspace content replication use cases

$
0
0

Problem/Motivation

In #2784921-137: Add Workspaces experimental module @catch presented a use case where a user may wish to pull content from one workspace, and push to a different workspace. In the analogy of git this may be similar to a merge.

Proposed resolution

The initial patch for the Workspace module in #2784921: Add Workspaces experimental module will only allow content replication to and from the live workspace. Therefore we need to look at how replication will work with other workspaces from both a technical and user point of view too.

In this issue we can discuss the possibly uses cases of content replication, and how users would like to be able to push, pull, and merge content between workspaces.

Limit the number of items per feed

$
0
0

In the Aggregator module, how can I limit the number of items per feed? I would like to be able to set a limit in the UI.

Firefox support for @-moz-document url-prefix() is being removed

$
0
0

Currently, in 8.6.x there are 4 instances of @-moz-document url-prefix() {} being used to supply Firefox only css. However, as of June 26th, 2018, with the release of Firefox 61, that rule will no longer be supported. Already, unsupported in dev/nightly/beta, which is why I noticed it since #2886904: display: block for details/summary hides drop arrows in Firefox (normalize.css update) didn't work. The reasons for removal are security/CSS injection/exfiltration.

Three of the instances, are related to a fieldset width Firefox bug that was fixed over 2 years ago. These should probably be removed when #2390621: [policy, no patch] Discuss aligning Drupal's browser support with jQuery 3's. Decide on exceptions. is finally resolved.

Suggested Fix

Using _:-moz-tree-row(hover), .selector works in all Firefox versions since 3.5 (as far as I can tell, didn't actually test all the way down to there.

Testing

Testing the change related to #2886904: display: block for details/summary hides drop arrows in Firefox (normalize.css update) is easy:
- Using Firefox 61 (or a beta/dev release since 59)
- Navigate to admin/config/system/site-information
- Confirm that the arrow shows on the summary/details element and toggles on opening/closing the element.

Functional testing the changes related to fieldset width would require a very old Firefox version and I believe it can be skipped as long as a code review shows the changes are equivalent.

Viewing all 291721 articles
Browse latest View live


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