I have a few blocks that have more links that point to URL's other than View pages. I've previously used the Footer section to provide these links, but thought it might be easier if I could enter a custom URL in the Link Display section for a block...
What do you think?
Render entity with Datetime Range field throws error:
Error: Unsupported operand types in Drupal\datetime_range\Plugin\Field\FieldFormatter\DateRangeDefaultFormatter->viewElements() (line 64 of core/modules/datetime_range/src/Plugin/Field/FieldFormatter/DateRangeDefaultFormatter.php).Needs to initialize array before assignment.
N/A
N/A
N/A
N/A
Another follow-up to #2796581: Fields must store their region in entity displays.
Somehow not caught in #2809527: Add backwards compatibility layer for entity display default config that lacks 'region'.
For extra fields that are included in default config, their initial loading will trigger
Undefined index: type in Drupal\field_ui\Form\EntityDisplayFormBase->determineComponentAction() (line 664 of core/modules/field_ui/src/Form/EntityDisplayFormBase.php)There is code to handle extra fields, but does not correctly handle them if it is coming from default config.
Write tests
N/A
N/A
N/A
If revisions are enabled and a media item is changed on later revisions, it's no longer possible to delete the original media item from the library, despite removing all revisions or the node in it's entirety.
The media item is added to the node using an image field.
Steps to reproduce:
Create a node and add media
Create a new revision and change the media
Delete the node
The original media item will remain in the library and cannot be deleted
ContentEntityBase keeps track of the status of each translation - (TRANSLATION_REMOVED, TRANSLATION_EXISTING or TRANSLATION_CREATED). There are use cases in contrib, where this information needs to be accessed. Therefore the feature request to add the getTranslationStatus function to the entity API. This funciton was as well mentioned in #1810370: Entity Translation API improvements.
In order to make it work properly removeTranslation should completely remove any trace of a translation which has been added and then removed without being saved, in this case removeTranslaiton sets the status to TRANSLATION_REMOVED, which from the point of getTranslationStatus is wrong, as the translation did not existed yet, it was added and removed without saving it. The proper return status should be NULL.
The second change should be done in addTranslation. If an existing translation has been removed and afterwards added again (wihout saving) the translation status would be TRANSLATION_CREATED, which from the point of getTranslationStatus is wrong, as the translation existed already, it was removed but not saved and added again. The proper return status should be TRANSLATION_EXISTING.
Third change : After creating a new entity it had the TRANSLATION_EXISTING status, but it should be TRANSLATION_CREATED.
Fourth change : After saving the entity the translation states have to be updated.
Additionally there is the new interface TranslationStatusInterface, which ContentEntityBase implements and provides the new function TranslationStatusInterface::getTranslationStatus($langcode).
Review.
none
none.
Change record - https://www.drupal.org/node/2789903
none
When disabling JS in the browser, fields cannot be moved to the Disabled/Hidden region.
Steps to reproduce:
Install Standard profile, log in as admin
Go to admin/structure/types/manage/article/display
Disable Javascript
Using the "Parent" dropdown, move a field from Content to Hidden
Click Save
Expected:
Field will now be in Disabled section
Actual:
Field will be in the unlabeled top section
Note, the "Content" region is not given a label, and the "Hidden" region is labeled "Disabled"
Also, updating the weight while JS is off works fine
It appears that the value selected for the "Parent" input is ignored.
\Drupal\field_ui\Element\FieldUiTable::tablePreRender() uses \Drupal\field_ui\Form\EntityDisplayFormBase::getRowRegion() to determine the region, which just inspects the formatter/widget.
None
When JS is disabled or when tabledrag is turned off, a "Region" column appears in the Field UI.
N/A
Data model changes only:
Field components in entity displays now have a region.
Adding a exposed filter to a view, and going to that view page leads to a notice, Notice: Undefined index: type in Drupal\views\Plugin\views\filter\Date->acceptExposedInput() (line 125 of core/modules/views/src/Plugin/views/filter/Date.php).
Date::acceptExposedInput is called two times in the views rendering build process (ViewsExecutable::build()) , first time through $exposed_form->renderExposedForm() and second time through $this->build('_filter'). Date::acceptExposedInput is aware that calling its parent will unset the 'type' property it's using, and thus try to restore it.
There's a few early return before the reset though, and when those early return hits, the second acceptExposedInput call won't find the array key it's looking for.
Restore the 'type' key before any early return in Drupal\views\Plugin\views\filter\Date::acceptExposedInput().
Starting from a Standard profile installation:
At this point, you'll be greeted with the aforementioned notice. Note that it doesn't show up in the view preview.
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.
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.
Manual testing and review.
N/A
N/A
N/A
Currently we are discussing at couple of issues why it is wrong to rebuild a content entity form with the entity that has been newly generated by the user submitted values by setting $this->entity = $entity in ContentEntityForm::validate.
The following test coverage shows that rebuilding the content entity form with the entity generated based on the new user submitted values will break the correct mapping of the submitted values to the corresponding field items when having complex fields with more than one property and only a part of the properties are to be edited by the user, which means that the user submitted ones have to be mapped to the corresponding field items they are originally coming from / built for.
The main issue where we've addressed this topic is #2675010: Cloned entity will point to the same field objects if the clone was created after an entity translation has been initialized.
I think that this deserves its own issue, as this is a complex topic and it has not been documented why we are rebuilding entity forms with the modified entity, but we do not rebuild content entity forms the same way.
A test field with two properties and a widget for this field where the one property is for user input and the other one is of type hidden.
Test that after rearranging the items the user input will be mapped to the corresponding field items and not mixed up.
Review.
After #2675010: Cloned entity will point to the same field objects if the clone was created after an entity translation has been initialized lands in then create an additional test for translatable entities with multiple translations.
None.
None.
None.
Spin-off from #2164601: Stop auto-creating FieldItems on mere reading of $entity->field[N]
The notion of "computed property" is pretty clear - typically, $field->field_ref->entity.
This is defined at the level of a property definition, for example in FieldItemInterface::propertyDefinitions() :
$properties['entity'] = DataReferenceDefinition::create('entity')
->setComputed(TRUE);
This means the property value will never be stored, and is lazy-computed on request by some custom code in the corresponding Data class.
The notion of "computed field" is still quite shaky.
It can be defined at the level of a field definition, for example in FieldableEntityInterface::baseFieldDefinitions() :
$field['foo'] = BaseFieldDefinition::create('string')
->setComputed(TRUE);But the actual effect of that is quite unclear at the moment. The only sure thing is that storage will never try to store the field values.
This is the current state of our discussions with @fago in Ghent. For clarity, this tries to expose the concepts of "computed properties" (pretty much OK in HEAD currently) and "computed field" (still largely TBD) side by side.
Sample case: EntityReferenceItem->entity
Behavior: don't save or load the value of that property when saving/loading the items, the value is populated on read at runtime.
The existence of a computed property is not field-by-field, it is determined by the field type, in the propertyDefinition() method of its Item class. It necessarily relies on the property definition providing a custom property class that implements the "compute the value" logic.
Also, the schema() method will likely omit to declare a schema column for that property, so nothing can be stored for that property anyway (well, at least in SQL - schemaless storage probably require some code to remove the value before storing the entity).
Sample case: a "back reference" field (a field that lists all the entities that have an entity_ref field pointing to that entity)
Behavior : don't save or load *anything*, we don't know whether there are items and how many, that will be determined on read at runtime.
--> In other words, the "computed" thing here is the FieldItemList.
This is field-by-field, specified by the individual field definitions, and is not tied to the field type. You can define a computed field of any existing field type. That necessarily relies on the field definition providing a custom FieldItemList class, that implements the "compute the existing items" logic.
This raises the question : how can a configurable field be made "computed", since the only way to specify that custom List class currently is in runtime code ? A back_ref field would typically be manually added by site admins, and would thus need to be configurable...
Also, the field type can happen to have computed properties, that's orthogonal. For example, a back_reference field could be a field of type entity_ref, with a computed ->entity property in each item that loads the referencing entity (that's for illustration's sake, in reality it would probably have more specific needs and be a separate field type that extends entity_ref).
In short, the two "computed" operate at different levels:
- computed field means : don't store anything, I'll tell you which Items exist at runtime
- computed property means : in each item that exist (however they happen to exist, stored or computed), don't store that property value, I'll tell you the value at runtime.
Create test-passing patches implementing progressively more complete computed fields:
DX of creating hook_theme implementations in a hook is not good.
Also, it is difficult for themers to find the contents of these functions. The plan has been that themers shouldn't have to read any PHP if possible.
Move into configuring hook_theme implementations inside yml. That would be a self-documenting way to specify contents of hook_theme implementations. This would be especially powerful in combination with #2809683: Make it required to specify variables passed to templates.
Deprecate hook_theme from Drupal 8 and mark it to be removed from Drupal 9.
Original report:
Potential problem: FAPI element '#description' only accept filtered text. Hence, check_plain() missing from Line # 85 of modules/aggregator/aggregator.processor.inc
Adding a patch for the same.
----
Problem: No description is shown on the "Default processor settings" fieldset.
Solution: ensure the same description appears in D7 as in D8.
If a user navigates away from a page while an AJAX request is running they will get an error message saying "An AJAX HTTP request terminated abnormally"
Skip displaying the message if the user deliberately aborted (for example, by reloading the page or navigating to a different page) while the Ajax request was still ongoing. See, for example, the discussion at http://stackoverflow.com/questions/699941/handle-ajax-error-when-a-user-...
Splitted out the patch by David_Rothstein (that was already reviewed and marked RTBC by @Fabianx) from #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors
Added by @droplet:
I understand this patch provided by David_Rothstein only. But we all in #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors spent a hard time on it with the different thoughtful idea & patches.
git commit -m 'Issue #1232416 by hanoii, nod_, heddn, geerlingguy, lokapujya, David_Rothstein, mangy.fox, xurizaemon, timfernihough, jibran, effulgentsia, j0rd, joelpittet, temkin, slashrsm, maxi Todorov, leewillis77, droplet, showrx, orbiteleven, opdavies, rooby, yechuah, shabana.navas, nikunjkotecha, ehj-52n, jhedstrom, sah62, edutrul, rfay, seutje, drupalshrek: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors'
Commit
N/A
N/A
N/A
Drupal’s new CSS coding standards recommend a naming convention for classes which requires the use of double-underscores as separators in certain cases. However, Drupal currently processes some classes internally using drupal_clean_css_identifier(), which replaces all underscores with dashes.
Allow double underscores to pass through drupal_clean_css_identifier untouched, if the allow_css_double_underscores variable is enabled. Because many modules rely on the current behavior of this function in order to generate standard dash-separated class names from php strings such as field_name (and this does not need to change), we should for the time being retain the existing behaviour for single underscores. #1109854: Overly aggressive transliteration in drupal_clean_css_identifier removes underscores from classes exists to discuss altering the treatment of single underscores.
None.
None.
None.
#1995272: [Meta] Refactor module CSS files inline with our CSS standards
#1109854: Overly aggressive transliteration in drupal_clean_css_identifier removes underscores from classes
The UI added by drupal_add_tabledrag() does not function at all on tested touch screen devices.
if you drag an element on top of another one it becomes a child and goes away from the current screen, very much like a folder behave in a file manager lambda.
As inferred from chat transcript at: #36
prototype & implementation.
needs prototyping & detailing.
not applicable
The UI added by drupal_add_tabledrag() does not function at all on tested touch screen devices.
One possible solution is to change the default functionality to the 'page weight' boxes when touch events are disabled.
This issue has been reported privately to the security team but it was decided to handle this as public security improvement since no direct vulnerability is involved.
Watchdog messages should be inserted sanitized into the database, but it is easy for developers to make the mistake of inserting user provided text as log message.
We should add an additional safe guard and do Admin XSS filtering when the log message is displayed in the user interface.
Write a patch against dblog.module
none.
none.
drupal_write_record is not using backticks (`) for column names. This leads to SQL syntax errors when using reserved keywords as column names.
This behaviour was observed with 'loop' as column name with mysql-5.1.
Querying using backticks around the column name (eg. "SELECT `loop` …") works normally.
Proposed solution would be for drupal_write_record to use backticks for all column names.
As I do not know if the solution would have to be made in drupal_write_record itself or somewhere 'further down' in the database system, I set the priority to major, since it could turn up anywhere in that case.
If you do happen to know that this issue is limited to drupal_write_record, feel free to set the priority back to 'normal'.
Follow-up to #2083649: Rename action module to action_ui
The textfield input for "user field" is #required, but has no label (the label is held by the table header) and thus shouldn't have a lone red asterisk. Seven correctly omits the marker if the label is empty.
Example of a form 'multiple, required' field form Bartik :
Seen in #501408: Display user fields on registration form, but is also visible in current HEAD when editing an existing user account with fields.
| Issue category | Bug because the information of the field being required should not appear twice |
|---|---|
| Issue priority | Major because tim.plunkett said so ;) |
| Unfrozen changes | Unfrozen because it only changes markup on fields widget that are set as required and allowing multiple values. |
| Prioritized changes | The main goal of this issue is usability and accessibility. Usability by hiding a non-pertinent mark near the input field. Accessibility by providing a valuable label for the multiple input fields. |
| Disruption | This change could be disruptive for themes because it forces some form labels to be hidden. |
For these cases mark the title_display as hidden:'#title_display' => 'invisible',
| Task | Novice task? | Contributor instructions | Complete? |
|---|---|---|---|
| Create a patch | Instructions | Done | |
| Reroll the patch if it no longer applies. | Novice | Instructions | Done |
| Update the issue summary | Instructions | Done | |
| Update the issue summary noting if allowed during the beta | Instructions | Done | |
| Add automated tests | Instructions | Done | |
| Manually test the patch | Novice | Instructions | Done |
| Embed before and after screenshots in the issue summary | Novice | Instructions | Done |
| Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards | Instructions |
Yes, the red asterisk moves to the correct location AND accessibility is enhanced by a better label around the fields.
<h4 class="label form-required">My unlimited required field label</h4>
[...]<label for="edit-field-unlimited-0-value" class="form-required"></label>
<h4 class="label form-required">My unlimited required field label</h4>
[...]<label for="edit-field-unlimited-0-value" class="visually-hidden form-required">My unlimited required field label (value 1)</label>n/a
In #2799021: Ensure a failing PHPUnit test shows enough information via run-tests.sh we added code to allow for PHPUnit test results in simpletest/run-tests.sh reports.
Unfortunately, this results in duplicate fail/error reports in the testbot and other tools, due to extraneous processing of Junit results, among other problems: #2602248: Test result rule name cut off
Finally there is confusion about the meaning of the various result codes sent back by PHPUnit. We often conflate exceptions with runtime errors, and we use integers when we should be using constants.
We should normalize on status codes, using a set of constants that are more global in scope than those in run-tests.sh. Accomplish this by creating a TestStatus class which all code can use.
simpletest_run_phpunit_tests() should be modified to not include the junit results of fails, exceptions, or system-level problems.
Follow up to add use of TestStatus wherever we deal with test results. Namely run-tests.sh.
Modify simpletest ui result form so it doesn't display errors as exceptions.
Modify the testbot system to adapt to changes from this issue. #2602248: Test result rule name cut off