Added "/api/*" pattern to the FE redirect ignore list. Also made private function/variable protected. If someone is inheriting this class for overriding, protected function/variable helps to override it directly, while using the rest functions as it is.
sijumpk → changed the visibility of the branch 3503311-typeerror-arraykeys-argument to active.
sijumpk → changed the visibility of the branch 3503311-typeerror-arraykeys-argument to hidden.
sijumpk → changed the visibility of the branch 2.3.x to hidden.
sijumpk → created an issue.
This issue is occurring during bulk content update (publishing/unpublishing) with content administration form (/admin/content). Fixes added for the issue.
Please add a release for this change
@smustgrave, it was a point worth watching. I missed that portion and Layout builder is using its own logic to list the blocks. Now its fixed and also a test case for that added to an existing test file.
Updated the MR to 11.x version. Now tests are working as expected.
sijumpk → changed the visibility of the branch 3388358-setprefix-when-the to hidden.
Current MR is only for 11.x.
Added test case to the branch 3388358-setprefix-when-the
Attaching test case for the issue. Patch made from the branch 3388358-setprefix-when-the . Tried committing to the branch, but was unsuccessful. So adding it as a patch
sijumpk → changed the visibility of the branch 3388358-setprefix-when-the to hidden.
In that case we can avoid this problem by removing "links" from patternProperties regex of "attributes" definition (jsonapi/schema.json > definitions > attributes > patternProperties). Thats the place this error is getting triggered. In case of "relationships" definition, just "id" and "type" are blacklisted in its regex (patternProperties).
In order to avoid changes to patternProperties, we can declare "links" as a field using hook_entity_base_field_info. By doing so we can make "links" a reserved one and could avoid making a field with that name. But the problem is that we can't do it in jsonapi.module. If we do so, someone can create the field by temporarily disabling jsonapi module.
The test case you provided is added to the current MR. Unfortunately the test case is not getting failed on running pipeline. I could generate the failing case in my local. Here is the passing pipeline details.
https://git.drupalcode.org/issue/drupal-3350525/-/jobs/824500
The status code (200) and response are printed in it. Any idea why its getting passed in the server only?
The keyword "links" is considered as a json response property just like "meta". Because of that when the string is validated against the JSON Schema (jsonapi/schema.json), its getting failed. In a normal scenario (in D10+), we can't add a node field without "field_" prefix. So this won't be a problem unless we create node fields problematically.
@smustgrave, your are right. We can do the testing using just Functional test only, like in case of ImageUploadTest. So the FunctionalJavascript test is now replaced with Functional test. Also changed the MR to 11.x version. Please review it.
Had committed the problem fixing code to 11.x branch, because of that the test-only pipeline was not showing any problem. Now 11.x is reverted back to its original state and added changes (the fix and updated test) to a separate branch. Here is the test result for test-only pipeline https://git.drupalcode.org/issue/drupal-3076346/-/jobs/806000. And its getting failed as expected. Please review it.
Tried removing the problem fixing portion from the code, leaving test only in MR. By doing so the MR got failed with the desired error message. You can see the job results here
https://git.drupalcode.org/issue/drupal-3076346/-/jobs/762582
Now the fix is added back to the code, and MR is getting completed without errors. No idea how the test-only pipeline got passed last time. Now I have rebased the code also, so this time lets hope test-only will work as expected.
'class' attribute should be an array. Seems like in case of Geofield Map, its passing a string instead of an array. Because of that this error is happening. Noticed that inside core code, there are some places where double checking for array elements are happening. Eg inside ClaroPreRender::verticalTabs
$groups_are_present = isset($element['group']['#groups']) && is_array($element['group']['#groups']);
So adding the same type of checking for $element['#attributes']['class'] also.
The error fixing portion is reverted back, and now there is just the test in the current MR. You can see that its getting failed with the desired error message. https://git.drupalcode.org/issue/drupal-3076346/-/jobs/762582.
So technically the test-only feature should also have to fail. How can this be possible? I also did a rebasing this time, maybe that helped. Anyway if you can check the current failed MR and confirm about the test case, I will add back the fix to the MR.
Tried recreating the issue in Drupal 10 and was unsuccessful. D10 is using CKEditor 5 and this patch is not needed for the alignment to work.
Altered the code to fix the existing problem and test case also added.
Problem/Motivation
Disbled block type displays of views appears in block UI/layout builder adding list.
Steps to reproduce
- Create a standard D11 installation
- Go to Content view edit page (admin/structure/views/view/content)
- Add a Block type display to the view and rename it "Test block"
- In the view edit page disable the block by cliking "Disable Test block" link
- Save the view
- Go to Claro's Block layout page (admin/structure/block/list/claro)
- Click on "Place block" button for any region
- Our disabled block, "Test block", appears in the list
Proposed resolution
Hide disabled view blocks from the block adding list.
Merge request link
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Added failing test as patch file, disabled_views_block_failing_test.patch →
sijumpk → changed the visibility of the branch 3415771-private-videos-upload to hidden.
@divya.sejekan, In order to see the updated list after disabling the block, you should reloaded blocks UI page or reopened the "Place block" popup after closing it.
Updated the code in such a way that if the display property is null, it will be changed to TRUE. Now media uploading to CKEditor5 will get displayed without any problem.
This is not just happening with Private files, even if we use Public files as Upload destination, same thing happens. But if we disable the Enable Display field option for file field, embedding will work file for both private and public files. That's how the option is set for the default Video media type (/admin/structure/media/manage/video/fields/media.video.field_media_video_file). Media library is using Drupal\media_library\Form\FileUploadForm for form generation, which is not handling the 'display' option like in Drupal\file\Plugin\Field\FieldWidget\FileWidget. Because of that field_media_video_file_1_display will get set as NULL instead 1.
Updated in such a way that the disabled blocks wont appear on add new block UI/layout, but existing added blocks will appear as such in UI.
You are right, unlike $info property, $wrappers doesn't have service_id key in it. Updated the documentation to reflect that and removed references to hook_stream_wrappers.
If we add a delta to one of the filter keys, the issue is not happening.
Eg:
https://d10dev.ddev.site/jsonapi/node/news?filter[field_news_type.field_tag]=type1&filter[field_news_position.0.field_tag]=position1
But this wont fix the problem if the node taxonomy field is a multi valued one and has multiple terms added.
This issue still existing. Was able to recreate it with Drupal 10.2
@cilefen, In drupal 10.2 also this issue is present. Checked myself and its not a time zone difference problem. Adding "steps to reproduce" to the issue summary. Seems like the cache is not getting cleared for json responses during access action (even if time is greater than 3 minutes). But its working correctly for login and changed. Also for the web version its working fine (with a clearing delay of session_write_interval=180s)
There is one more place in message.schema.yml, where this type of sequence definition is used (line 89).
message.message:
type: mapping
label: 'Message settings'
mapping:
purge_enable:
type: boolean
label: 'Purge messages'
delete_on_entity_delete:
type: sequence
label: 'Auto delete messages referencing the following entities'
sequence:
- type: string
label: 'Entity type'@abhaypai, your patch will cause an "Access denied" to /admin/structure/block/add/page_title_block . In order to avoid that _access_theme: 'TRUE' is avoided from block.admin_add route. We need to add a block even if there is no theme present in the url
Even without patch, things are working fine. So was not even able to reproduce the bug. The screen recording I provided is taken without applying any patch. So according to me the functionality is working as designed, and there is no need for the patch. There by not review needed and no RTBC.
Followed all the steps provided in the issue summary for reproducing the bug. If in case I missed something, it will be helpful if @smokris can provide some more details. Or may be someone else can try to recheck for the existence of this bug.
@Graber, there is nothing you missed. Just changed the status from "Needs Review", may be "Active" is better. By doing so, some others can also try to reproduce the error. Or you can change it to "Postponed (maintainer needs more info)"
There is a page available to add block to any theme, at admin/structure/block/add/page_title_block. Because of that _access_theme: 'TRUE' requirements is avoided from block.admin_add route. Even if we reach the page like you said (admin/structure/block/add/page_title_block/non_existance_theme), we won't be able to create any block as there wont be any options available in the required "Region" field.
Today checked with the current latest dev version and is showing up fine.
@johnnydarkko, Normally going to /admin/modules (as said in the issue summary) is not making any errors. Maybe some custom/contributed module's links are generating the problem. Try to recreate the problem by disabling all non-core installed modules.
Checked "Manage form display" from Drupal+Claro version 10.1.6, and its showing the gear icons properly (see attached screenshots). I checked it from both Ubentu Firefox and Chrome. May be this is a browser related issue. Which browser and OS are you using?
Patch #2 is changing FieldDefinitionInterface to FieldConfig, which wont fix the problem. Both BaseFieldDefinition and FieldConfig are implementations of FieldDefinitionInterface. In order to fix the issue, argument type of hook_field_purge_field in field.api.php should be changed to FieldDefinitionInterface.
Tried recreating the error (without patch), but things are working fine. Upon checking the page source, the script /core/misc/ajax.js?v=10.1.6 is getting loaded in the page, which contains Drupal.ajax. It seems like things are working as expected even without the patch. Created the screen recording as a non-admin user, let me know if I missed something.
Drupal version used is 10.1.6 and VBO version 4.2.x-dev.