🇺🇸United States @j. ayen green

Fixed pattern rather than using the proposed alternative.
'/^mailto:\/\/[\w\.\-]+@([\w\-]+\.)+[\w\-]{2,4}$/'

j. ayen green → created an issue.

j. ayen green → created an issue.

So it was weirder weirdness than I thought. It was some docker container glitch. rfay had me clean up docker, power off ddev, turn off mutagen, start it up (messages were gone), power off again, turn on mutagen and start it up, and the messages are still gone.

For anyone who might have the same issue, these were the commands:

ddev poweroff
docker rm -f $(docker ps -aq)
ddev mutagen reset 
ddev config global --performance-mode=none 
ddev start

see if the messages are gone

ddev poweroff && ddev config global --performance-mode=mutagen && ddev start

No, you didn't, I did :-) I just went back (a couple messages up) and formatted it as code.
Ok, I do appreciate your spending the time. This issue seems to be on the cusp of Linux and Drupal...not sure where it will fall. I'll head over to Slack with a pitstop first at ddev.

That command made
sites/default/files
sites/default/files/php
sites/default/files/php/twig
and all the files in them 777

Yes, what I meant was I've tried chmod -R 777 sites/default/files, which made php and php/twig 777, and no joy.

I have been, but even setting all folders from files on down to 777 just to test it had no effect. As for the web server process user, this is on ddev, and all the ddev environments (of which this is the only one with the issue) are the same user/group. Could this be an nginx setting, or something to do with .htaccess?

j. ayen green → created an issue.

j. ayen green → created an issue.

@FeyP thanks! I was looking in the wrong place!

The new permission doesn't seem to be present in D10.

j. ayen green → created an issue.

I've recreated the issue in D10. The code (below) is quite simple. I can upload the view config, but it's simply a content view of articles set to display 10. I'm including a screen capture of xdebug.

<?php
use Drupal\views\ViewExecutable;
use Drupal\views\Plugin\views\query\QueryPluginBase;


/**
 * Implements hook_views_query_alter().
 */
function itemsperpage_views_pre_render(ViewExecutable $view) {

  if ($view->id() == 'itemsperpage') {
    $view->pager->setItemsPerPage('5');
    $x = $view->pager->getItemsPerPage();
  }

}

j. ayen green → created an issue.

What seems to be happening is that when the select options are passed back to views via addfilter however many options were selected then all have the value of the final selection.

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.