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

Label translation does not visible for built in fields

April 22, 2016, 5:03 am
$
0
0

In a newly created Drupal site the Label field of the Article node type is not offered for translation by the Configuration translation module. However, after modifying the original English label text, it will be shown in the translate form.

To reproduce:

  1. Install a new Drupal site:
    drush site-install standard --db-url=mysql://drupal810:drupal810@localhost/drupal810 --site-name=Test --account-name=admin --account-pass=password -y
    drush en config_translation -y
  2. Log in as admin and add a new language (I added the Hungarian) to the site (sorry, I did not find working Drush command for this step)
  3. Go to the translate link (/admin/structure/types/manage/article/translate) and Add translation to the Article type

Here you will see the Name, Description and Explanation or submission guidelines fields, but not the Label. If you modify the original field (/admin/structure/types/manage/article) by setting the "Explanation or submission guidelines" still the Label remains untranslatable. But when you modify there the "Title field label" (e.g.: EngTitle), in the translation page there will be two additional elements: the "Label" and "Help text" fields.

↧
Search

Implement Entity Reference Backreferences

May 30, 2015, 10:54 am
$
0
0

Prior Art
In D7 we had needed https://www.drupal.org/project/entityreference_backreference for exposing backreferences in the entity API. Some other modules and discussions

Use Case
Content type A has an entity reference field to Content type B. Getting to Content type A from B would be impossible without entityreference backreference module in other modules that build on the entity api, such as Search API or Rules...

↧
↧

sport

December 26, 2016, 10:37 am
↧

Unable to Publish/Unpublish from Content Admin Screen when content_moderation enabled

November 7, 2016, 4:10 pm
$
0
0

Enabling the "Content Moderation" module breaks the bulk operations at /admin/content for all content types, even ones that don't have Content Moderation enabled for them specifically.

This makes some sense when Content Moderation is enabled, because it fundamentally changes the publishing workflow for these node types. For the others, to my eye it is just an overzealous permissions restriction.

Those publish/unpublish operation should probably be adapted to handle this situation, since they are in core, as a part of pulling content moderation into core. This issue, however, is only for the inappropriate permissions blocking for content types that are not using Content Moderation.

Related issue: https://www.drupal.org/node/2804105

↧

Fatal error when viewing node with content moderation enabled if a module which implements hook_node_grants() is enabled

October 24, 2016, 7:09 am
$
0
0

Problem/Motivation

Using content moderation module on a site where there is some modules which implements hook_node_grants() generate a fatal error when viewing node moderated which have not been yet published.

This issue is a follow up of #2821599: Coexistence of PBF and content_moderation, where i provided a temporary workaround.

I can reproduce this bug with any modules which implements hook_node_grants(). Tested with Permissions by fields, Content Access and a tiny custom My module which implements only an empty hook_node_granst() function.

Steps to reproduce :
- configure a new clean install of drupal 8.2.1
- enable the module content_moderation and configure it to be used on the content type "Article"
- create a new role named "Editor" and some users. Enable all the content_moderation permissions related to "Article" content type for Editor.
- Create two node Article 1 and Article2. Publish the Article 1. Let the Article 2 in draft state.
- Now the users belonging to the "Editor" role can see and edit the two articles written by each other.

- Enable pbf module (or any module which implements hook_node_grants()), or generate a custom module with Drupal Console and implements hook_node_grants() in this module.

- Editor users can see and edit Article 1
- When Editor users try to see Article 2, a fatal error occurs

Fatal error: Call to a member function isRevisionTranslationAffected() on null in core/modules/content_moderation/src/ParamConverter/EntityRevisionConverter.php on line 101

The acquireGrants method in NodeAccessControlHandler provide a default grants[] only if a node is published.

if (empty($grants) && $node->isPublished()) {
  $grants[] = array('realm' => 'all', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0);
}

Then for nodes which have never been published, the getLatestRevisionId() method in the Class ModerationInformation returns always an empty value, and then the fatal error occurs.

Proposed resolution

Check if the latest_revision is an instance of EntityInterface, in the convert method of EntityRevisionConverter Class. See patch attached.

Remaining tasks

Review the patch and/or
Is there an another root cause of this issue ?

User interface changes

No changes

API changes

I believe not

Data model changes

I don't think

↧
↧

When enabling moderation apply a relative state

October 13, 2016, 7:36 am
$
0
0

Problem/Motivation

When enabling moderation on a bundle the moderation state is not set on existing entities, therefore it gets the default state, which is often 'draft'.

Proposed resolution

When enabling moderation on a bundle the moderation state should be set to an unpublished state on unpublished revisions, and a published state on published revisions.

Remaining tasks

User interface changes

API changes

Data model changes

↧

Url::fromRoute does not understand Russian characters in the query option

July 4, 2015, 8:20 am
$
0
0

Code:

        \Drupal::service('link_generator')->generate($title, Url::fromRoute('yarcom_sphinx.search_type', array('search_type' => $t), array('set_active_class' => TRUE,'query' => array('q' => $i['query'],
          ),
        )));

If $i['query'] is russian characters, css class is-active does not appear.

Example 1:
$i['query'] = 'комацу' (russian characters).
Browser address bar: http://dev.******.ru/search/yarcom_news?q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86...
Html code:
<a href="/search/yarcom_news?q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86%D1%83" data-drupal-link-query="{&quot;q&quot;:&quot;\u043a\u043e\u043c\u0430\u0446\u0443&quot;}" data-drupal-link-system-path="search/yarcom_news">News entity</a>

Example 2:
$i['query'] = 'komatsu' (english characters).
Browser address bar: http://dev.*****.ru/search/yarcom_news?q=komatsu
Html code:
<a <strong>class="is-active"</strong> href="/search/yarcom_news?q=komatsu" data-drupal-link-query="{&quot;q&quot;:&quot;komatsu&quot;}" data-drupal-link-system-path="search/yarcom_news">News entity</a>

In the first example q=%D0%BA%D0%BE%D0%BC%D0%B0%D1%86%D1%83" and data-drupal-link-query="{"q":"\u043a\u043e\u043c\u0430\u0446\u0443"}" are not identical.

↧

Add experimental Field Layout module to allow entity view/form modes to switch between layouts

September 6, 2016, 7:09 pm
$
0
0

Problem/Motivation

Expand the Field UI to switch between two layouts: one column and two column (left/right)
Since this issue depends on #2296423: Implement layout plugin type in core, modules and themes will have the ability to provide new layouts.

Proposed resolution

Add an experimental module named Field Layout.
It enhances Entity Display entities to store a layout, and enhances the Field UI to expose those settings.

Remaining tasks

N/A

User interface changes

Previously the Field UI showed all fields either in a "Content" region, or as "Disabled".
This will remain unchanged by default, additional layouts are opt-in.
There is an details element at the bottom to allow switching between layouts.

API changes

N/A

Data model changes

N/A, field_layout uses third party settings to store the data

↧
Search

Add support for Quick Edit to the Content Moderation module

October 8, 2016, 4:47 pm
$
0
0

Problem/Motivation

At the moment, Content Moderation and Quick Edit are incompatible. If users are viewing a moderated entity, Quick Edit is only available on the default revision, which goes against Content Moderation's workflow of always editing the live revision. This can lead to tricky problems and bugs.

For example, enable moderation on an entity bundle, publish a draft, then create a new draft of that entity. If you visit the default (published) revision and use Quick Edit, the draft is discarded as Quick Edit is only aware of the default revision of any given Entity! This is really confusing for content editors (and may be considered a bug).

Proposed resolution

There are a number of steps that need to happen to make these modules work together:

  1. Use the EntityRevisionConverter to pass the correct Entity revision to Quick Edit paths, in the same way Content Moderation currently handles Entity Forms.
  2. Ensure that Contextual Links display on the latest revision of a Node. Otherwise Quick Edit will be inaccessible to users.
  3. Make sure that the ModerationStateWidget does not interfere with Quick Edit operations.
  4. Disable Quick Edit on non-latest and live revisions of moderated entities.

Remaining tasks

Review the provided patch.

User interface changes

None.

API changes

Quick Edit routes provided by inline editors will need to set the route option "quickedit_entity_route: TRUE" so that Content Moderation knows to swap what revision is provided for moderated Entities. This was an explicit way to add this support, as Quick Edit routes are not required to share any similarities and the alternative would be to hard-code routes (see my Workbench Moderation patch from #2749503: Add basic support for Quick Edit).

\Drupal\content_moderation\Entity\Handler\ModerationHandlerInterface will get a new method, entityViewAlter, which will allow handlers to perform modifications on a built moderated entity. This is used by \Drupal\content_moderation\Entity\Handler\NodeModerationHandler to disable Quick Edit on individual revisions and ensure that contextual links on the latest (non-default) revision are rendered normally (typically non-default revisions of Nodes have different contextual links).

Data model changes

None.

↧
↧

Programatically creating a published entity doesn't result in a published entity.

December 26, 2016, 10:38 am
$
0
0

Problem/Motivation

If you create a node and call setPublished and immediately save it and call isPublished, you'll find the entity is unpublished when it belongs to a bundle that is being moderated.

Maybe this is the correct behaviour based on the developer not specifying a moderation state, but it's not how it used to work, so it's worth at least an issue discussing what should happen.

(Note, the pass in #7 and fail in #20 in #2825579: Unable to Publish/Unpublish from Content Admin Screen when content_moderation enabled indicates the timeline for when the change occurred, likely the workflow component split).

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

↧

Clean-up unused variable and useless method call from LanguageRequestSubscriber

December 26, 2016, 2:56 pm
↧

Clearing cache via UI in translated language resets config translation of field labels to default language

January 14, 2016, 10:11 am
$
0
0

Problem/Motivation

I translated field labels through the configuration translation module UI. When I create a node and then translate it the translated version reflects translated field labels so for example fr/node/nid has all labels translated. However if I clear the cache while still being on translated page (any path with language prefix) all labels become English (default language) again. If I switch to default language and then clear cache one more time then switch to French labels are translated again.

Basically every time the cache is cleared through UI while on the page with language prefix fr/... it resets translation for previously translated configuration items. And when the cache is cleared on default language the translation is back to normal.

On the site all multilingual core modules are enabled. Translation is enabled for content types and for fields. Default language of the site is English. Nodes were created in English with French translation.

Steps to reproduce

  1. Install all modules in Multilingual (language, locale, config_translation, content_translation)
  2. Added French language (any language should do) via /admin/config/regional/language
  3. Enable translation for Article under Content->Article at admin/config/regional/content-language
  4. Create a test Article node with some Tags content via /node/add/article
  5. View /fr/node/1 (or whatever), the Tags label should show as Étiquettes
  6. Navigate to /fr/admin/config/development/performance and clear cache via the UI
  7. Back to /fr/node/1 and the Étiquettes label is now "Tags"

Proposed resolution

After further investigation revealed that the translations getting cached while clearing cache in a state language override isn't in place. Which causes the system to save english/default translation into language prefixed cache key. This is caused by triggering entity title call in views route subscriber. Moving title of the route to title callback fixes the problem.

Remaining tasks

Manual testing and review.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

↧

taxonomy_term_load_parents_all() doesn't work correctly with multiple hierarchy terms

February 4, 2008, 6:49 am
$
0
0

Status:
A partial fix has been committed to D7 in #346156-14: term delete fails because of misnamed function.
However, per #13 and a duplicate issue against D7 (see #19) this still doesn't work correctly.
A new patch against D7 is available in #16

#1347542: [META] Taxonomy API improvements
#251595: Add taxonomy_term_load_descendents()
#346156: term delete fails because of misnamed function
#394422: Taxonomy terms should be listed in order they are entered
#1207326: Refactor taxonomy hierarchy API for performance, consistency, and convenience

Original report by Pancho

Suppose you have a multiple hierarchy vocabulary with the following terms:

Politics (tid=1)
-- Event (tid=2)
Sports (tid=3)
-- Tennis (tid=4)
---- Event (tid=2)

Calling taxonomy_get_parents_all(2), you would expect an array with all ancestors of the Event term.
Instead, the array contains (in this order) only the terms Event, Politics and Tennis, while Sports is missing.

If you add a positive weight to Politics, you receive the following vocabulary:

Sports (tid=3)
-- Tennis (tid=4)
---- Event (tid=2)
Politics (tid=1)
-- Event (tid=2)

Calling taxonomy_get_parents_all(2) now gives you the expected array with all ancestors of the Event term: Event, Tennis, Politics and Sports.

So the search for ancestors starts with the branch that has the least weight and then bounces between the branches, searching for another generation of ancestors. But as soon as any ancestor has no more parents, the complete search is stopped.
Instead it would be correct to keep on analyzing the other ancestors if they have more parents.
In the first example: Politics has no more parents, so the algorithm still spits out Tennis, but stops then. Correct would be to abandon the Politics branch, but keep on crawling the Tennis branch. Then we would have found Sports as well.

I also think it would make a lot of sense to add parents to the output array. Maybe we also want some control over how many parent generations are displayed. But these are nice features for D7, not the D6 bug itself.

↧
↧

Few spelling typos

November 20, 2016, 5:02 pm
$
0
0

Typos: statc, Contructs, optioanl, correclty, Snice, sttings, moncerus, file_save_htacess(), thre, perfoming, glueing, meothd, vlaue.

-    // internal statc caching of FileCache is used and thus avoids blowing up
+    // internal stat caching of FileCache is used and thus avoids blowing up

maybe not 'stat', but 'stat()' or 'status'?

↧

Add a SQL index for entity types that are using EntityPublishedInterface

December 9, 2016, 4:21 am
$
0
0

Problem/Motivation

Now that we have a generic interface for publishable entities, a lot of queries will need to take the entity status into account.

Proposed resolution

Add a SQL index for <status_key>_<bundle_key>_<id_key> just like we have for nodes.

Remaining tasks

Review, agree, etc.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

↧
Search

Add phpcs, coder 8.2.8 as --dev requirements for drupal/core

June 7, 2016, 5:10 pm
$
0
0

Problem/Motivation

Now that we're well on our way to managing coding standards in a reproducible way: #2571965: [meta] Fix coding standards in core

...let's just add the tools to core's composer.json dev requirements.

That way we don't have to instruct people how to install them beyond saying "run composer install --dev"

Proposed resolution

Modify core/composer.json to add drupal/coder and squizlabs/php_codesniffer as a dev requirement.

Add an install script to composer.json which adds coder's code_sniffer as an installed_path.

Remaining tasks

Update documentation such as https://www.drupal.org/node/1419988 and https://www.drupal.org/node/1587138

User interface changes

API changes

Data model changes

↧

Weird spacing in words in footer

December 27, 2016, 2:30 am
$
0
0

I've got a design issue in latest Drupal 8 version with Bartik theme. I've made you a screenshot, see this link: https://s29.postimg.org/qbd8l5zsn/error.jpg or view the attachment. There are 3 German words in it: 'Kontakt', 'Impressum' and 'Datenschutzerklärung'. The first word has a font issue at the ending (between a and t) and the third word has an issue with latest character having a big space between the previous character. It looks ugly and isn't intended by me.

↧
↧

menu_cache_clear description contains duplicate word: cached cached

December 22, 2016, 7:06 am
↧

inaccurate description for EntityTypeManager::getHandler()

October 19, 2016, 6:10 am
$
0
0

API page: https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Entity!EntityType...

> Creates a new handler instance for a entity type and handler type.

That's not true. It caches the instantiated handlers and only creates one if needed.

Rather than say 'creates', the documentation should explicitly state that handlers are per entity type, not per entity.

This is so developers know that they may statically cache something in handler, but also to ensure the cache is per entity if necessary.

↧

Exposed filter criteria gives internal server error on edit in rest view

December 27, 2016, 1:10 am
$
0
0

Exposed filter criteria gives internal server error on edit in rest view.
I have created a rest view for articles content.
We have a filter Authored By exposed.
Filter criteria was successfully added and works fine.
But when I try to edit the filter criteria, I see the following error in the browser console -
POST http:///example.com/admin/structure/views/ajax/h..._export_1/filter/uid?_wrapper_format=drupal_ajax 500 Internal Server Error 324ms
"NetworkError: 500 Internal Server Error - http://example.com/admin/structure/views/ajax/handler/articleslistexport..."
uid?_wr...al_ajax
AjaxError:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/views/ajax/handler/articleslistexport/rest_export_1/filter/uid
StatusText: Internal Server Error
ResponseText: {}
administration-reports-recent log messages shows-
Location http://example.com/admin/structure/views/ajax/handler/articleslistexport...
Referrer http://example.com/admin/structure/views/view/articleslistexport/edit/re...
Message InvalidArgumentException: The #default_value property has to be an entity object or an array of entity objects. in Drupal\Core\Entity\Element\EntityAutocomplete::valueCallback() (line 68 of /home/ubuntu/projects/drupal/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php).
Severity Error

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