Latest patch applied successfully for me on D10 with Scheduler 2.0.3 (tested with dev branch as well).
The main publish/unpublish workflow is functional but I noticed some issues with the admin UI:
As per comment #20 - point 1, it is with "Paragraphs (stable)" form display widget that the publish/unpublish date fields disappear once the node is saved.
With "Paragraphs (stable)":
- Scheduling options are not shown anymore once the node is saved, no matter how the scheduler fields are displayed (Vertical tab / Separate fieldset)
- If the node itself has scheduling options, the paragraphs scheduling sections are displayed but empty, either above the node scheduling options section ("Vertical tab" display, see attached screenshot for example) or in the paragraph edition section ("Separate fieldset" display) and each paragraph displays scheduling fields according to node scheduler configuration (i.e. If node is configured to use scheduler for "Publishing" only whereas Paragraphs are configured for both "Publishing"/"Unpublishing", only "Publishing" field will be shown in paragraphs.
With "Paragraphs Legacy" form display, none of the above happens and everything works well.
Tested on Drupal 10.2.6 / S3FS 8.x-3.4 / WebP 8.x-1.0-rc2 with responsive image style and I can confirm that patch #7 works with this configuration and Webp images are correctly created in the bucket.
Applied MR!5 and ran command
./vendor/bin/phpcs --standard=Drupal,DrupalPractice --extensions=php,module,inc,install,test,profile,theme,css,info,txt,md,yml,twig modules/contrib/addthis_social_share
No more PHPCS errors are shown.
misterdidi → changed the visibility of the branch issue/3372573-phpcs to active.
misterdidi → changed the visibility of the branch issue/3372573-phpcs to hidden.
Tested patch #6 with D10.2.5, php8.2 and views_rss 2.2, it works for me as well.
Can confirm that patch #4 works on D11. I created a fork with the patch.
Can't create a MR, though.
misterdidi → made their first commit to this issue’s fork.
Hi,
Isn't
https://www.drupal.org/project/cocoen_beforeafter →
doing the same thing?
Hi,
Although patch #5 works fine, I wonder if it is a good idea to rely on yet another external font library for such a small change.
IMHO, since boxicons font seems to be abandoned, I believe moving to fontawesome and getting rid of boxicons font would be a valuable change.
Would be glad to have maintainer's opinion on that point.
I had a look at the code for further investigation and ajax works fine. Problem is $element['settings']['maxlength']['#default_value'] (this value is correctly updated) being overriden by $form_state->input value in TextWidget::widgetSettingsForm().
Maybe adding a condition to reset the input to the default value if it is out of range would fix the issue.
Hi,
I identified the issue and can provide a manual workaround until a patch can be made.
Problem is: When creating a new custom field, a new "Text (plain)" item is created by default with a 255 maxlength (Custom field items section of the page) + a new row is added in the bottom table for the item field settings (including maxlength). If you unfold the "Settings" tab of your field item row, you can see the maxlength parameter.
Now, when you update the maxlength value from the "Custom field items" section (e.g. 150 characters), it does not update the maxlength value in the table row "Settings" tab (although it should) which remains at 255 characters. Hence, when you try to save the form or add a new item, the form does not validate because the values do not match (see attached screenshot for example).
Manual workaround is to edit both maxlength fields to get rid of the validation error.
Checked D10 compatibility with Upgrade Status and Drupal Rector: only change needed to be the core_version_requirement tag.
misterdidi → made their first commit to this issue’s fork.
This is more like a boxicons font issue (font used for the icons). The font files should be updated. Problem, the font has not been updated for 2 years, now. There are quite a few issues regarding the twitter logo on the official github repository (https://github.com/atisawd/boxicons/issues?q=is%3Aissue+is%3Aopen+x+icon) but none of them seems to have been officially addressed.
It's been quite a while since it was published, but I applied patch for php7.2 compatibility. Patch is working fine.
As per https://api.drupal.org/api/drupal/core%21modules%21layout_discovery%21la..., service plugin.manager.core.layout is part of the core module Layout Discovery.
I created a fork to include this dependency in the .info.yml file.
Attached is a patch for immediate use.
misterdidi → made their first commit to this issue’s fork.
The warning message being displayed in hook_view_presave() if no caching option is manually set by the user, I added the view label (not sure view id would be more understandable) to the warning message so that user is aware of which view was automatically updated.
misterdidi → made their first commit to this issue’s fork.