When you enable priorities in the Views UI under Table settings, it begins to trigger PHP warnings, along the lines of:
Notice: Indirect modification of overloaded element of Drupal\Core\Template\Attribute has no effect in template_preprocess_views_view_table() (line 555 of core/modules/views/views.theme.inc).
Merge into an attribute object.
After path aliases are converted to entities, we should also convert their forms to extend content entity form base classes.
Convert custom path alias forms to entity forms.
Do it :)
Nope.
Nope.
Nope.
When using a views exposed form as block. The block does not allow you to provide a title.
Patch provided
None
None
None
I have created a simple Views page with several exposed filters with Views option: Exposed form in block: Yes.
The block is configured to "Display title" in block config settings.
When the block is configured to display in a region, the Label/title is not displaying.
I have dumped the block variables out with template_preprocess_block() and label key is empty ('label' => string(0) "").
The result is the same when the block is configured to override title.
Is this a bug or have I missed something?
Trying to set language specific config, for example Spanish site name:
$ drush -y config:set language.es:system.site name "Hola Mundo"
Raises the following exception:
Invalid character in Config object name language.es:system.site.
Whereas the following two commands just work fine:
$ drush config:get language.es:system.site name
'language.es:system.site:name': 'Hello World'$ drush -y config:set system.site name "Hello World"
// Do you want to update name key in system.site config?: yes.in core/lib/Drupal/Core/Config/ConfigBase.php inside public static function validateName($name) the following
// The name must not contain any of the following characters:
// : ? * < > "' / \
if (preg_match('/[:?*<>"\'\/\\\\]/', $name)) {
throw new ConfigNameException("Invalid character in Config object name $name.");
}
may better be
// The name must not contain any of the following characters:
// : ? * < > "' / \
// Except for language-specific collections.
if (!preg_match('/^language.[a-z]{2}:/', $name)) {
if (preg_match('/[:?*<>"\'\/\\\\]/', $name)) {
throw new ConfigNameException("Invalid character in Config object name $name.");
}
}
to exclude at least language-specific collections from invalid character check. Although I'm not sure if it's not even better to make that a more general solution, for example if there are other collections than language collections. But are or can be there any other collections except language collections?
* patch provided
* reviews needed
* tests to be run
* documentation to be written
- None -
Unsure about that.
- None -
While working on #2616814: Delegate all hook invocations to ModuleHandler, we discovered that workspaces_entity_load() takes its $entities argument by reference, which violates the hook_entity_load() interface.
Introduce hook_entity_load_alter() to directly solve the problem in the Workspaces module, and hook_ENTITY_TYPE_load_alter() to make this alteration behavior consistent with the other entity API hooks.
None.
None.
None. These are additions only.
None.
Currently it does not seem to be possible to sort a config entity query through the third party settings.
return $this->getQuery($this->keys, $this->category, $this->state)
->sort('third_party_settings.custom_module.last_updated', 'DESC')
->execute();
This seems to be because the execute() method of \Drupal\Core\Config\Entity\Query\Query does not handle nested properties in the way the conditions on the query are handled.
Parse fields in the same way the conditions for the config entity queries are handles (so split the field by dot).
Discuss the solution, add some tests.
Followup #2999721: [META] Deprecate the legacy include files :
Convert tablesort.inc functions to a static class.
Implement table_sort service and deprecate all tablesort.inc provided functions
None.
tablesort_* functions will be deprecated and removed at Drupal 9 release.
Will be introduced a new static TableSort class.
None.
The entity_view function has been deprecated for some time now and only used in a couple of places. Let's go the home stretch, remove the final usages from core and trigger a deprecation warning when the method is called by implementing modules.
The entity_view_multiple function has been deprecated for some time now and only used in 8 places. Let's go the home stretch, remove the final usages from core and trigger a deprecation warning when the method is called by implementing modules.
Follow-up of #2567257-210: hook_tokens() $sanitize option incompatible with Html sanitisation requirements:
Posting this here for now, will probably open a follow-up issue.
I've been working on updating token.module and adjusting functionality/tests for this. Which is probably something we should have done before committing this, to make sure that this works for more than the few use cases that core has.
I think there is at least one example there why supporting some sort of sanitize => FALSE is useful and important.
The basic use case is when you have user-provided, unsafe input and want it to be continue unsafe and un-escaped, because you then rely on autoescape.
One example in token.module is the block label, it has this code:
function token_block_view_alter(&$build, BlockPluginInterface $block) { $config = $block->getConfiguration(); $label = $config['label']; if ($label != '<none>') { // The label is automatically escaped, avoid escaping it twice. $build['#configuration']['label'] = \Drupal::token()->replace($label, array(), array('sanitize' => FALSE)); } }The problem is that now the block label tokens are escaped twice. There's a test that is creating a node with a ' in it, and right now, that is getting escaped twice (which is exactly what this code is testing), since we force-escape all token return values and then escape the whole string again.
I don't see a proper way to fix this right now. What technically works is using PlainTextOutput::renderFromHtml() but clearly it is not correct to use that in non-plaintext output.
We don't have to pass it to hook implementations, but I really think we need a flag to prevent auto-escaping. We even document:
The caller is responsible for choosing the right escaping / sanitizationbut don't actually allow to caller to do that, at least not for token values. But if the token input is untrusted and will be escaped later, we must treat token replacements as untrusted too or we are guaranteed to have double-escaping problems?
(See also the following comments about some discussion and why various things don't work IMHO)
Add an option that does nothing but skip the Html::escape() and always returns the token value as-is.
It does *not* pass that through to hook implementations. To make it clear that it is not the same as the old sanitize option, it should probably be named differently, e.g. 'escape' => TRUE/FALSE, defaulting to FALSE.
Some modules need to act before an entity is loaded, and swap out the default revision with a different one.
For example, the Workspace module in core swaps the default revision with a workspace-specific revision, if one exists.
Add two new hooks: hook_entity_preload() and hook_ENTITY_TYPE_preload() that are called before the entity loading process.
Discuss, review.
Nope.
API addition, the two new hooks mentioned above.
Nope.
Follow-up of #2389335: Deprecate entity.query service and replace with using the entity storage's getQuery() method. Can likely be done in parallel as the other issue adds nothing new.
The annotation for /core/lib/Drupal/Core/Entity/FieldableEntityStorageInterface::countFieldData()
specifies the type for $storage_definition.
but the function definition does not. I like strongly typed interface definitions.
I think we are missing an obvious trick.
Nodes are not saving with inaccesible pre-existing referenced items.
Issue has been fixed once with the ticket: https://www.drupal.org/project/drupal/issues/2791269 stating, "Allow saving pre-existing references to inaccessible items" means there should not be any validation check for the existing referenced items.
Still the node save was disallowed and throwing an exception : "This entity (node: 32) cannot be referenced."
On cheking deeper the solution contains a condition:
/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/ValidReferenceConstraintValidator.php
@@ -119,32 +119,31 @@ public function validate($value, Constraint $constraint) {
+ // Check if any of the invalid existing references are simply not
+ // accessible by the user, in which case they need to be excluded from
+ // validation
+ if (isset($previously_referenced_ids[$target_id]) && isset($existing_entities[$target_id]) && !$existing_entities[$target_id]->access('view')) {
+ continue;
+ }
Accordingly, the clause !$existing_entities[$target_id]->access('view') is causing problem in my casue.
here, the condition is failing becasue the "test user" has "view access" for the referenced unpublished node ceated by himself.
It is not only the problem with "view own unpublished content" permisisons. When you have any other Node access module enabled like Domain Access or content modertion. The issue get more severe and requires a broader scope.
Becasue user will be editing a node shared on different domains consisting different doamins (assigned) entity references.
I'm still working on getting used to D8 since moving from D7. I keep noticing the notice that I should take care of a security risk about display oEmbed content in a frame that is served from the same domain as your main Drupal site. I go to the page at admin/config/media/media-settings, but I am lost as to what I'm supposed to do. I read the links about what the problem is, but what am I supposed to put in the form box? It kind of makes it sound like I'm meant to set up another domain to point to my main one. Is that it?
Updated: Comment #0
#2161845: Node views (front page, admin) do not use the proper language filter is not quite the expected behavior.
If
node 1 is in en (source), es, af
node 2 is in es (source)
node 3 is in af (source), en
And people create a view (like the front page) which is "List all the nodes in the page's current language",
the expected result is to see 3 nodes (all the nodes). Assumes fallback, see list in proposed resolution section, is show node in source language.
If the page language is en, then expected is: node 1 in en, node 2 in es, node 3 in en, is expected. (Optional expectation is that users with translation permission could see a link to translate node 2 into en. Separate issue?)
If the page language is es, then expected is: node 1 in es, node 2 in es, node 3 in af.
Add fallback to language filter, with choices of what to do when there is a result, but not a result in the language being filtered by.
Fallback choices could be:
a) show node in source language (the "language of the node", note that nodes do not have to exist in the site default. For example a site default might be en, but a node, like node 2 above could have been created in es, or node 3 created in af)
b) show node in site default language
c) show node in X language detection and negotiation method... like user account preferred language, browser language
d) hide node.
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Update the issue summary | Instructions | ||
| Update the issue summary noting if allowed during the beta | Instructions |
No?
No?
Hi,
my multilanguage site is configured to show language prefixes on paths, but didn't expect to see the language prefix in the value of the[site-url] token too, and it seems it is not possible to pass options for the global tokens either in token_token_values().
To prevent the language prefix from showing in the url, we can use this snippet
$values['site-url'] = url('<front>', array('absolute' => TRUE, 'language' => ''));
Let me know if the change looks OK to you, in this case I can send a proper patch.
Thanks,
Antonio
Placeholder issue.
I added a Base Field of type 'comment' to a content entity type.
When adding a comment into the comment form, I got an error from Comment::preCreate() that FieldStorageConfig is not an object.
I'm guessing that base fields don't use FieldStorageConfig?
Is there anyway to define a custom node operation ?
This could be helpful for a clone op, for example, where the user can't update the original node, but has more possibilities than just viewing it.
Such an op should, of course, then be available to all access hooks such as hook_node_access, hook_node_grants and hook_node_access_records.