It seems that views query parameters through the URL does not result in them being passed on to the query.
I have narrowed it down to the difference between $view->exposed_data and $view->exposed_input. As far as i can tell from the code, exposed_input is the parameters fetched from either form submission or URL, and exposed_data is only as it is through form submission.
exposed_data is used a couple of places, where it does not make sense to only handle data through form submission.
If a field containing an inline SVG is passed through views rewrite results the SVG is stripped and mostly removed (normally just leaving the the title left).
The same field containing an inline SVG can be used on a normal node page without being stripped.
Views rewrite uses \Drupal\Component\Utility\Xss::filterAdmin() which has protected strings of protected static $adminTags = array('a', 'abbr', 'acronym', 'address', 'article', 'aside', 'b', 'bdi', 'bdo', 'big', 'blockquote', 'br', 'caption', 'cite', 'code', 'col', 'colgroup', 'command', 'dd', 'del', 'details', 'dfn', 'div', 'dl', 'dt', 'em', 'figcaption', 'figure', 'footer', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'header', 'hgroup', 'hr', 'i', 'img', 'ins', 'kbd', 'li', 'mark', 'menu', 'meter', 'nav', 'ol', 'output', 'p', 'pre', 'progress', 'q', 'rp', 'rt', 'ruby', 's', 'samp', 'section', 'small', 'span', 'strong', 'sub', 'summary', 'sup', 'table', 'tbody', 'td', 'tfoot', 'th', 'thead', 'time', 'tr', 'tt', 'u', 'ul', 'var', 'wbr');
Adding some SVG specific strings such as those found in the following popular purifiers would allow common SVG markup and keep it safe from XSS.
https://github.com/cure53/DOMPurify/blob/master/src/purify.js
or
https://github.com/darylldoyle/svg-sanitizer/blob/master/src/data/AllowedTags.php
A section (not full list) by way of example of some strings those purifiers allow is:
'accent-height','accumulate','additivive','alignment-baseline', 'ascent','azimuth','baseline-shift','bias','clip','clip-path','clip-rule','color','color-interpolation','color-interpolation-filters', 'color-profile','color-rendering','cx','cy','d','dy','dy','direction','display','divisor','dur','elevation','end','fill','fill-opacity', 'fill-rule','filter','flood-color','flood-opacity','font-family','font-size','font-size-adjust','font-stretch','font-style','font-variant', 'font-weight','image-rendering','in','in2','k1','k2','k3','k4','kerning', 'letter-spacing','lighting-color','local','marker-end','marker-mid','marker-start','max','mask','mode','min','offset','operator','opacity', 'order','orient','overflow','paint-order','path','points','r','rx','ry','radius', 'restart','scale','seed','shape-rendering','stop-color','stop-opacity','stroke-dasharray','stroke-dashoffset','stroke-linecap','stroke-linejoin', 'stroke-miterlimit','stroke-opacity','stroke','stroke-width','transform', 'text-anchor','text-decoration','text-rendering','u1','u2','viewbox', 'visibility','word-spacing','wrap','writing-mode','x','x1','x2','y', 'y1','y2','z',The issue can be worked around by simply not passing SVGs through views Rewrite results.
It would be worthwhile confirm that adding common SVG strings to the existing XSS filtering would be safe. Is it?
Are there other HTML elements that are safe to add but which we do not permit? (broaden issue?)
The 'Add forum' and 'Add container' forms refer to term instead of forum:
Update the form element descriptions to correctly refer to 'Forum' / 'Container'.
Form element descriptions on 'Add forum'/'Add container' correctly refer to 'Forum' / 'Container' respectively.
None
When configuring an entity reference field for users, you can choose to disallow anonymous user selection. However, this only works when providing the list of autocomplete values, but is completely ignored during validation. It seems that this bug even allows you to bypass the "required" flag of the field.
You can see this bug by:
Expected behavior:
The entity reference autocomplete widget should throw a validation error saying "Foo bar (0)" is invalid, just like it would with "Foo bar".
When showing radio buttons, people with 'administer users' are shown Anonymous as an option because of some logic in UserSelection not setting any condition and thus selecting all users (including UID 0) from the {users} table.
One annoyance with the "out-of-the-box" experience when creating new entity types is the lack of redirects from add, edit and delete forms.
Implementing a redirect in the form class itself is possible, but different entity types might redirect to different routes. Nodes, for example, redirect to the canonical node types redirect to the collection route.
If there is a collection route with a list builder, most likely the user wants to return to the list after editing or deleting an entity, regardless of where that form would otherwise redirect.
Thus, let's add a destination query parameter to the operation links in the list builder.
This is already done explicitly, for example, in the node listing, so is an established pattern.
The operation links of list builders will include destination query parameters so that the user is redirected back to the list builder after performing the operation. In core this should not affect anything because we already have explicit redirects in all of the form classes.
None.
None.
Follow-up to #2744197: Proper private file support for images uploaded via EditorImageDialog: without the patch in #2744197-81: Proper private file support for images uploaded via EditorImageDialog, all private images uploaded via EditorImageDialog are giving 403.
This is easily reproducible on simplytest.me:
1. Install Drupal w/ standard profile
2. Add an article node with garbage info
3. Create a view with base table of Content Revisions, displaying fields.
4. Add field "Tags" under category "Content (historical data)"
5. In settings for that field, rewrite the field using "Override the output of this field with custom text" (actually doesn't matter what you pick, you just need something that exposes the replacement tokens)
6. Observe that the replacement token for that field contains a hyphen: "{{ field_tags-revision_id__target_id }}"
The problem is that you cannot have hyphens in twig variables like that. I believe it should be two underscores instead based on what I've seen in some other issues.
This causes a couple issues:
1. There's an assertion in PluginBase::viewsTokenReplace() that checks if tokens are valid twig variables. So if the token replacement is performed for whatever reason, this assertion will fail and cause a 500 error.
2. I believe this would also prevent twig from performing the replacement correctly and/or using the proper field template for the field, but I can't be sure because I didn't test that behavior.
I did a little big of digging and see that the token name for a given field is literally the "id" of the field, see FieldPluginBase::getFieldTokenPlaceholder(). Not sure on the solution here since I'm completely unfamiliar with this code.
A couple people have WTF'd at this. It was added to stop people from guessing if they should use is_subclass_of or class_implements.
In #2448503: Convert the "Field edit" form to an actual entity form$form_state->unsetValue(array('field', 'settings', 'handler_submit')); got removed and ever since it is stored in field config.
Remove 'handler_submit' button value form ER field config.
None
None
None
Let's look at the following plugin:
/*
* Defines a fallback plugin for missing block plugins.
*
* @Block(
* id = "broken",
* admin_label = @Translation("Broken/Missing"),
* category = @Translation("Block"),
* )
*/
class Broken extends BlockBase {Where is the problem? Its hard to spot ... ... Its a missing asterics on the first line.
Somehow protect against this stupid but insane hard to debug problem.
One approach could be to add some check in \Drupal\Component\Annotation\Plugin\Discovery\AnnotatedClassDiscovery::getDefinitions
In ContentEntityBase::__clone clear the translation cache before cloning the fields in order to ensure the cloned fields will get an entity translation reference of the cloned entity instead of the original entity.
The decoupling of the object properties has to be done as well before cloning the fields as this will cause cloning of the clone when initializing the translations of the clone and we want to prevent that ::initializeTranslation will create references to the properties of the original entity.
Review & Commit.
None.
None.
None.
Based on 10.2 and Array.size() is not a valid method
I was fighting a strange problem that config schema validation failed due to a string/integer mismatch when saving config in a form.
Turned out that it was a classic Heisenbug, as it only existed because I had a debug($config->get()) call before calling save.
And what happens then is that overriddenData is initialized. Then you save, it casts all the data and saves it correctly. Then comes \Drupal\Core\Config\Development\ConfigSchemaChecker::onConfigSave() and calls $saved_config->get()... and receives the old, overridden data and throws an exception.
Move $this->resetOverriddenData(); up, before actually writing the config and invoking the event.
Follow up for #1498674: Refactor node properties to multilingual
Simplify code
In 1498674 was the @todo
// @todo: Wouldn't it be possible to use $this->base_table and no if here?
On the line in the patch in comment #303:
3698
The line of the final patch might change but that info might help to find them.
For example,
// @todo: Wouldn't it be possible to use $this->base_table and no if here?
- if ($view->storage->get('base_table') == 'node_revision') {
- $this->additional_fields['nid'] = array('table' => 'node_revision', 'field' => 'nid');
+ if ($view->storage->get('base_table') == 'node_field_revision') {
+ $this->additional_fields['nid'] = array('table' => 'node_field_revision', 'field' => 'nid');
}
else {
$this->additional_fields['nid'] = array('table' => 'node', 'field' => 'nid');use $this->base_table and remove the if
No.
No.
Submit message button is hardcoded but there are other uses for contact forms.
Preview button always displays but sometimes you don't want it.
Add new properties to ContactForm entity - button text and show preview
Add these to the contact form schema
Add new fields to edit form to set the values
Alter the message form to use these new values to set the button text and preview visibility
Test coverage
All of the above
You can borrow elements from contact storage module
New form options in contact form edit form
None
None
We would like to request more options to edit the buttons through the Contact Form UI in Drupal 8:
Request #1: We would like to change the text of the contact form's submit button from "Send Message" to something else within the UI since we'd hope to use this module for several diverse small forms on our site. For instance, we have one form that's a Demo Download so "Get Download" makes more sense.
Request #2: We would like to either hide or remove the preview button within the UI as it's not always needed on our forms.
When #2831274: Bring Media entity module to core as Media module lands we'll have Media entity in core. But it won't be of much use if we don't provide any proper media plugins.
In order to replicate current image field behavior we need support for local images.
Adopt image plugin from Media entity image contributed module.
Besides that create a media bundle for local images with sane default configuration. Location of this bundles still needs to be decided as it could be in module that provides media entity, (experimental) module that implements media library (see: #2796001: [prototype] Create design for a Media Library), in standard or in an experimental profile.
- Adopt image media type plugin
- decide where media bundles will be defined
- create media bundle for local images
Setting the label display to "hidden" or "visually hidden" in the Contact Forms configuration does not seem to have any effect on the field label.
To reproduce:
Until a recent commit, submitting a contact form would display a "Your message has been sent." message to the user. This message is now configurable when creating/editing a contact form but, by default, no message is shown/set. As discussed in #2780763: Add missing parameter in ContactFormCloneForm::__construct(), we think that this is a UX regression and that the "Your message has been sent." message should be shown/set by default.