🇺🇸United States @j. ayen green

j. ayen green → created an issue.

j. ayen green → created an issue.

Package modified.

The use case we were investigating is having more granular control over imported styling when pasting content from Word. Any thoughts on whether there is an approach to this for CKEditor 5 in lieu of an upgrade path for this module?

Thanks for the commit!

1. Which version of Drupal?
2. Which version of drush?
3. Are your config files in project-root/config/ ?

There is no difference with plain text. It is a plain text field. The module validates the format when entering the URL. It has nothing to do with the rendering. If you, for example, enter https://z it will present an error when you attempt to save because the format is wrong. That is all the module does.

As to the name, URL is as meaningful as Phone. It is simply the type of field.

It would seem there are no technical issues remaining. If so, can we move on to the final step?

Commit payload added. 1.0.0-alpha2.

This issue seems stuck. Can we un-stick it, please?

j. ayen green → created an issue.

I like the idea of option 2. I'd like to add a use case here, as well. Having a component, such as an Event. There could be more than one display defined for the detail or teaser view, but both would be referring to the same component data so need a way to be supported by an appropriate variant.

Is this still an issue? I loaded Amp 3.8 and Devel 5.1 and am receiving no errors.
If you are current on the versions and are receiving the error still, please document the steps to reproduce the error.

Hi Christophe,

Since the site is still in alpha, I'm wondering if you had any particular architectural/functional changes in mind for it before resolving the issues and moving to beta?

One question I have, keeping in mind a lack of context at present, would it make sense to have the checklist items fed via an install yml from config rather than in code?

j. ayen green → created an issue.

@miwayha - Super find. Thank you for diving into it. It is perplexing, indeed. cweagans/composer-patches does seem like the home for this.

Was a separate issue forked from this for the semantics loss? I understand that semantics is less critical than data, but try to tell editors that their tables getting munged because CKEditor cannot handle th vs td.

It seems that prior to 10.1 there was an issue with a block save causing a "double save", and a patch issued for it. It also seems that the issue went away in 10.1, but the patch was still being applied, and instead of stopping the second save from occurring, it stopped the only save from occurring.

The 303 was a red herring. I'd gone too deep in debugging.

I've found in putting a breakpoint in BlockPluginTrait::setConfiguration that in a vanilla instance the change to the title in the block config form is reflected here, but not in the problem instance. I've pasted the call stack trace below. I'd greatly appreciate being pointed at a likely next place to look.

Stack: 
BlockPluginTrait.php:80, Drupal\Core\Block\BlockBase->setConfiguration()
DefaultSingleLazyPluginCollection.php:85, Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->setConfiguration()
ConfigEntityBase.php:165, Drupal\Core\Config\Entity\ConfigEntityBase->set()
ConfigEntityBase.php:295, Drupal\Core\Config\Entity\ConfigEntityBase->preSave()
Block.php:344, Drupal\block\Entity\Block->preSave()
EntityStorageBase.php:528, Drupal\Core\Entity\EntityStorageBase->doPreSave()
EntityStorageBase.php:483, Drupal\Core\Entity\EntityStorageBase->save()
ConfigEntityStorage.php:257, Drupal\Core\Config\Entity\ConfigEntityStorage->save()
EntityBase.php:339, Drupal\Core\Entity\EntityBase->save()
ConfigEntityBase.php:609, Drupal\Core\Config\Entity\ConfigEntityBase->save()
EntityForm.php:293, Drupal\Core\Entity\EntityForm->save()
FormSubmitter.php:114, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/Form/FormSubmitter.php:114}()
FormSubmitter.php:114, Drupal\Core\Form\FormSubmitter->executeSubmitHandlers()
FormSubmitter.php:52, Drupal\Core\Form\FormSubmitter->doSubmitForm()
FormBuilder.php:597, Drupal\Core\Form\FormBuilder->processForm()
FormBuilder.php:325, Drupal\Core\Form\FormBuilder->buildForm()
FormController.php:73, Drupal\Core\Controller\FormController->getContentResult()
EarlyRenderingControllerWrapperSubscriber.php:123, call_user_func_array:{/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:123}()
EarlyRenderingControllerWrapperSubscriber.php:123, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:121-124}()
Renderer.php:583, Drupal\Core\Render\Renderer->executeInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:124, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext()
EarlyRenderingControllerWrapperSubscriber.php:97, Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure:/var/www/html/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php:96-98}()
HttpKernel.php:166, Symfony\Component\HttpKernel\HttpKernel->handleRaw()
HttpKernel.php:74, Symfony\Component\HttpKernel\HttpKernel->handle()
Session.php:58, Drupal\Core\StackMiddleware\Session->handle()
KernelPreHandle.php:48, Drupal\Core\StackMiddleware\KernelPreHandle->handle()
PageCache.php:106, Drupal\page_cache\StackMiddleware\PageCache->pass()
PageCache.php:85, Drupal\page_cache\StackMiddleware\PageCache->handle()
ReverseProxyMiddleware.php:48, Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
NegotiationMiddleware.php:51, Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
StackedHttpKernel.php:51, Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
DrupalKernel.php:704, Drupal\Core\DrupalKernel->handle()
index.php:19, {main}()

This has been fixed in the new dev version. Thank you for the catch.

• Straightened out the storage schema and settings schema
• Fixed the PHPCS issues and made sure no new ones were introduced
• Replaced the placeholder README.txt with a complete README.md that adheres to best practices.

When I click the submit button in the block config form, stepping through in xdebug, I reach ::submitConfigurationForm() in BlockPluginTrait.

At this point $form_state contains the changed block title in $form_state->decoratedFormState->values[settings][label].

::blockSubmit() is then called.

It progresses to FormBuilder::buildForm() where ::processForm() is called and returns an EnforcedResponseException code of 303 (Other).

No error message is given on the screen, nothing logged, but the result is a return to the block layout screen with the config change not having been saved.

Raising the priority a notch to raise it a bit
in the stack as it’s been a couple week.

Hi. This seems to be stuck. Are you waiting for me to put back a method to generate a random value? Again, it’s not a required method, but if I need to put it back in order to finish this process please tell me.

This and other issues have been fixed. See the latest dev release or beta3.

I’m confused. It’s in FieldItem that the random value is generated, which is the field settings form, not the URL field value itself in the FieldWidget.

In the field settings form are the checkboxes to select the allowed schemes. By default http and https are set. What would need a random generation?

Changes made.

• validate is now called statically
• the generation of a default value for the field item form was removed as the default value is static
• handling of the element variable in formfield is now standard

Hi. Anything I can do to move this along?

I just tried, and cannot. Standing up a vanilla Drupal 10.1.7 site results in a block config save acting as it should.
Any idea of what to look for that might be impacting a config save that has changed from 10.0 to 10.1?

j. ayen green → created an issue.

Thanks for the catch! While your patch addresses null being returned, it also would prevent any scheme from being returned were any selected.

Where Drupal directs the user to check the boxes for the schemes that should be allowed, and says that if none are selected all will be allowed, it turns out that this is a promise to the user that needs to be fulfilled by the coder...it's not automatic. I had thought all values would be returned.

What I'm doing to fix this is that if null is returned from the field settings, I call the field item plugin to get the list of schemes and return that list instead of null.

The code changes are:

• Change the method in the field item to being public static
• Add a use statement in the field widget identifying the field item class
• Change the return from getSchemes() to be

return $def->getSetting('allowed_schemes') ?? UrlItem::getSchemes();

The results is that when no schemes are selected in the field settings, all are returned by getSchemes() and the resulting description under the text box is given as:

Enter a URL. Allowed schemes are: http://, https://, ftp://, mailto://, sftp://, ssh://, tel://.

You can pull the dev branch to get this change.

Corrected.

Thanks Vishal. That exposed that PhpStorm wasn't fully connecting to PHPCS. All items were addressed.

@TomTech #49 (using ddev and PhPStorm) ... I owe you a beer!

Hi. Yes, I believe the problem is that you are looking at the wrong branch. It should be 1.x.

fwiw, you are correct that on the branch you looked at that is a duplicate of the core class. It was named .bak because it wasn't to be used there, it was only copied into the folder to make it easier to refer to.

j. ayen green → created an issue.

laura.gates → credited j. ayen green → .

I know you're slammed (and know the feeling). Was wondering if there is a better way to communicate (i.e. are you on Slack?), where I can find out, as a first example, what I should look at to complete in order to move Production Checklist to beta.

Best,
Jeff

I think getting to beta as a step in reaching a full release should be a focus.

I'd be happy to be a co-maintainer!

j. ayen green → created an issue.

That did it! Is there a reason that this did not get done doing the overall composer upgrade, and does not show up in the composer outdated output?

views_ajax_history is 8.x-1.6

j. ayen green → created an issue.

Damien, the remote video url seems to defy attempts, though. The admin help shows the two URL subfields with a remote video field:
[node:NODE_FIELD:entity:field_media_remote_video_url]
[node:NODE_FIELD:entity:field_media_oembed_video]

Neither produce a URL. Not sure if it's a token issue or a metatag one.

I'm going to solve this myself. It seems the best place in this case to get the token format is from admin help for tokens rather than the places I've found suggestions.

The format that works is:

[node:FIELD_NAME:entity:MEDIA_FIELD_NAME:STYLE_NAME:height]
[node:FIELD_NAME:entity:MEDIA_FIELD_NAME:STYLE_NAME:width]
[node:FIELD_NAME:entity:MEDIA_FIELD_NAME:STYLE_NAME:mimetype]

j. ayen green → created an issue.

Hi. Yes, I did find the original request to add the feed and it's in #5. You're right...I'm confused as to how the date (on my site) ended up that way, since I published it a couple days ago, but that certainly explains it! Thank you for your quick reply and help :-)

I'm not sure what you're requesting. The feed has been active for years. I don't have the original request anymore.

The link is up in the description.

j. ayen green → created an issue.

j. ayen green → created an issue.

DOES media_duplicates work in conjunction with this module, i.e. will it prevent duplicates being created during a bulk upload?

If not, I think the ability to use some method, given a folder, whether file name or checksum would be great. One use case of the bulk upload is that people have media organized into various folders by some category, and do not want them put in year_month folders, as that does not make them easy to find at all. So, once the bulk upload of existing media in their existing folders has completed, what happens when more images are added to those folders? That's when it becomes important to be able to upload from a folder and either filter based on date added being after a certain date or have some means to avoid the previous items from being added again.