The scaffolding documentation link in README.txt refers to version Drupal 8.
see
https://git.drupalcode.org/project/drupal/tree/8.8.x/composer/Plugin/Sca...
Proposed resolution
see
https://git.drupalcode.org/project/drupal/tree/9.1.x/composer/Plugin/Sca...
Just a quick report about Font-your-face module and Claro, the view display seems to have problems (cf screenshot).
(Not quite sure about the Claro version, I have activated the one in Drupal 8.8.6)
Thanks anyway for this admin theme, really nice to use on a daily basis.
I am facing issue while overriding the View through twig template in Drupal 8. I have created the Unformatted View in D8 with fields. I have overrided the view fields with template named as views-view-fields--[view-machine-name].html.twig
But in my Drupal 7 website two templates are used views-view-fields--[view-machine-name].tpl.php and views-view--[view-machine-name].tpl.php . If in D8 I am using the template views-view--[view-machine-name].html.twig then whatever I have written in fields template of view is not coming.
Is there any way in D8 to do this. Can we use multiple twig template for single view? When I am doing the blank page is coming.
Content types are ordered by machine name on node/add but by name on admin/structure/types. This is inconsistent.
Order content types by name on node/add.
This is a followup to #3024682: Migrate UI - add human-friendly module names to the Review form. The patch in #105 over there contained out of scope changes which made it to RTBC but had to be removed. This is to preserve the improvement to the ReviewForm.
When adding aliases through the admin interface, there is a validation check (function aliasExists) to make sure you are not reusing an existing alias. Strangely the function does not prevent you from making a duplicate alias.
To reproduce, go to /admin/config/search/path/add and add an alias with a source. Then do it again (same alias, same source).
If you use different sources you will be stopped from reusing an alias, but nothing stops you from adding a duplicate. Why allow that?
Steps for reproducing the issue:
- Create a new menu
- Add a link
- Link Autocomplete only displays maximum 30 records
Expected Behaviour:
- Link Autocomplete display all the results matching the string (even if it exceeds 30 records number)
Please help. How can I fix it as I am really stuck with it. I tried menu_link but gives lots of error in installing. What else can i do to resolve it?
Thanks for the help.
When the batch API was converted into OO syntax the functionality was left as it was in Drupal 8.3 and before. Because of this an error can happen if the file passed into setFile() does not exist.
Update the the code in core/lib/Drupal/Core/Batch/Batch.php, as well as other files, to ensure the file exists and log the problem and throw an exception if it does not.
None
None
None
Currently when the media library does access checking on the entity that opened the media library, it does so by loading the entity using a simple \Drupal\Core\Entity\EntityStorageInterface::load. When editing inline blocks and layout builder both of these things are true:
Steps to reproduce:
What is happening under the hood:
\Drupal\layout_builder\EventSubscriber\SetInlineBlockDependency::isBlockRevisionUsedInEntity).::load call doesn't match the actual revision ID in the layout and the access chain is broken, resulting in an access denied.Pass the host entity's revision ID around, instead of it's ID and load that instead for the purposes of access control.
#2555899: Add test coverage for Comment link handlers handler introduces CommentViewKernelTestBase, CommentUserNameTest should extend from that to improve consistency throughout the tests.
When reverting to a previous revision of an item of content, the new revision created matches the moderation state of the revision being reverted.
While this keeps the integrity of the workflow in tact, since content can only be recreated in a state that was valid at some previous point in time, it may not always be what users expect and it limits the utility of reverting in general, since certain revisions can only be recreated and immediately published or can only be recreated and reverted back to a draft.
A few proposals have been made to address this issue:
@catch in #17 (paraphrasing):
@jhedstrom in #18:
@Sam152 in #30:
Agree and implement an approach.
Request: Provide configuration to disable AJAX for Views exposed form submission.
Current Code: If the view is enabled to "use ajax", then form submission and pagers are setup to use AJAX.
Use Case: Non-AJAX form submission with an AJAX pager. This case is useful when there are non-view related content on the page that needs to change based on the views results. Example: Facet blocks for Search API views.
This is a slightly obscure and minor issue that cropped up during #2350135: Duplicate path aliases can be added.
Around line 795 in EntityResourceTestBase::testPost(), we send an "invalid" POST request with multiple values for a single-value field.
$request_options[RequestOptions::BODY] = $parseable_invalid_request_body;
$response = $this->request('POST', $url, $request_options);
// DX: 422 when invalid entity: multiple values sent for single-value field.
if ($label_field = $this->entity->getEntityType()->hasKey('label') ? $this->entity->getEntityType()->getKey('label') : static::$labelFieldName) {
$label_field_capitalized = $this->entity->getFieldDefinition($label_field)->getLabel();
$this->assertResourceErrorResponse(422, "Unprocessable Entity: validation failed.\n$label_field: $label_field_capitalized: this field cannot hold more than 1 values.\n", $response);
}As shown, the request is always sent - but the error is only expected if the entity actually has a label field.
For entities that don't, this means that the "invalid" request goes through and actually creates an entity. There's no indication that the test expects this to happen. Therefore it seems correct that the "invalid" request is only sent if the test actually expects an error:
// DX: 422 when invalid entity: multiple values sent for single-value field.
if ($label_field = $this->entity->getEntityType()->hasKey('label') ? $this->entity->getEntityType()->getKey('label') : static::$labelFieldName) {
$request_options[RequestOptions::BODY] = $parseable_invalid_request_body;
$response = $this->request('POST', $url, $request_options);
$label_field_capitalized = $this->entity->getFieldDefinition($label_field)->getLabel();
$this->assertResourceErrorResponse(422, "Unprocessable Entity: validation failed.\n$label_field: $label_field_capitalized: this field cannot hold more than 1 values.\n", $response);
}When installing from scratch (with softaculous), a new installation of Drupal 8.9.1 crashes after saving a new default language (in my case Dutch). As from then, all admin links report error-500. Therefore no more administration acts are possible anymore.
I encountered this issue several times, as I have tried to re-install (upon re-install) until I quit trying. PHP version is 7.3.
Required fields are not identifiable on Internet Explorer 11 because the required marker is not visible. This field is supposed to have the required marker:
This is how this field looks like in Edge:
Ensure that required fields are identifiable on Internet Explorer 11 high contrast.
The default front page field description says: "Optionally, specify a relative URL to display as the front page. Leave blank to display the default front page." But if left blank, the front page redirects to /user, not /node (which is the default front page).
Either update the description to reflect the actual behaviour, or update the behaviour to show the default front page if this value is not set.
Original IS
I just installed D8, but when I try to reach the Front Page as an authenticated user, I got immediately redirected (302) to the user page. As a anonymous user, it works as expected.
I do not know exactly what additional data I should provide for debugging this issue, but will happly provided any information I can.
The HAL module's EntityReferenceItemNormalizer identifies the target_id and invokes the serializer to embed the referenced object in the HAL structures _links and _embedded properties. To minimize the amount of data embedded, the EntityReferenceItemNormalizer tweaks the $context parameter so only the uuid property is included on the embedded node. This has the secondary effect of preventing referencing fields out of that embedded object so they are not processed.
However, if you customize EntityReferenceItemNormalizer or ContentEntityNormalizer to include more of the "embedded" entity, you will include entity reference fields. Without the hard stop on recursing, any self-references or cycles will result in an uncontrolled recursion.
If you do override HAL to embed more data, you end up running entity loading in the serializer, with no clear way to add its now-significant cache metadata. Immediately referenced items by the loaded entity are not included, it appears referenced metadata is added in the rendering process which is not triggered for REST resources.
The goal as outlined is in making the HAL serializer more friendly to extension and customization, not to add new capabilities in what the HAL or REST modules offer by way of a more versatile API.
recursing element with a counter.Add tests for point 1, implement functionality and tests for point 2 and 3.
None.
* Additional metadata for serializer that can be ignored.
* Changes that may impact custom or contrib recursion protection implementations.
None.
In #2986452: Database reserved keywords need to be quoted as per the ANSI standard we fixed working with reserved keywords for queries. For the class Drupal\Core\Database\Schema there is nothing done. In #3023794: MySQL >= 8.0.2 Bug: Exception during module activation because of reserved keyword "GROUPS" we have a problem with using sites with the "group" module on Drupal 8 with MySQL 8. The problem should be fixed for Drupal 9, only for queries not for the class Drupal\Core\Database\Schema.
In #3033043: SQlite index names not quoted we have the problem: "An example of such a module is restrict_ip (https://www.drupal.org/project/restrict_ip) which defines an index named 'type-path'. The index name is perfectly valid on both MySQL and SQlite."
Add testing for working with reserved keywords in combination with the class Drupal\Core\Database\Schema. Add fixes where necessary.
TBD
None
None
None
TBD
For the committer: Please give user @jsst commit credits for his work on #3033043: SQlite index names not quoted.