🇺🇸United States @pookmish

This is not something supported by this module.

MR opened, and patch provided for any composer patches.

pookmish → changed the visibility of the branch 3480225-disabled-displays-can to active.

pookmish → changed the visibility of the branch 3480225-disabled-displays-can to hidden.

pookmish → created an issue.

By changing the edit form to not use the admin theme, it is possible to use the default theme instead of the admin theme. This can be done by altering the existing route → .

  protected function alterRoutes(RouteCollection $collection): void {
    if ($route = $collection->get('entity.mailchimp_campaign.edit_form')) {
      $route->setOption('_admin_route', FALSE);
    }
  }

I've updated the image style derivative flush.

pookmish → changed the visibility of the branch 8.x-1.x to hidden.

pookmish → changed the visibility of the branch 3220671-empty-text to hidden.

Re-rolling patch from #6 for latest 1.6.0 version. I'll create a MR as well.

With the latest release, I was able to correct this without a patch by checking the option "Create label before first save" for new content.

Re-rolling the patch to be used in composer.json patches for version 1.10. I'm not creating a MR since there seems to be a lack of clarity on the direction of the desired solution at this time.

MR from #3 works as expected. There is minimal changes and nothing functionally different. Please release a Drupal 11 supported version.

Thanks for the provided MR. It solved the issue I was having.

pookmish → created an issue.

I added a unit test for the maintenance mode page assets. It works as expected. @hswong3i, if your site is sending "null" into the hook_preprocess_maintenance_page then you have other things that are breaking the functionality. Even Drupal core expects an array in the hooks for claro and olivero themes.

Patch does not apply due to change in the code. Please resubmit as a MR

pookmish → changed the visibility of the branch 3459347-correct-spelling-rename to active.

pookmish → changed the visibility of the branch 3459347-correct-spelling-rename to hidden.

pookmish → created an issue.

Oh yeah, sorry. Looks like it was caused by the patch in ✨ Don't block content menu links reordering Needs review

Please provide any steps to reproduce or more information on the situation. Especially since this is added to the page, not the view.

Please add the return type declaration.

Yeah, I wasn't sure if this issue should be closed or postponed, or what.

Leaving open in case anything else comes through via the bots.

Merge conflicts exist in the MR due to another issue getting merged. Please update the MR.

I feel like this is an unnecessary bloat to the already complex form. And comments can often be placed directly in the JS/CSS asset. If there is a desire for notes field, it would be straight forward to modify the entity type to add the field.

The MR seems to address more testing than the actual feature requested, and the feature requested is entirely just a cosmetic change the form. No functionality changed. This works for me.

MRs aren't merging for me, so I'll commit and push up

Thanks for this.

I seem to be getting "An error occurred while merging. Try again." on all MR. I've commit the old fashion way.

I like this new approach. I hope it solves the s3 issue as well.

A couple things to change in the MR:
add docblock & return type to the new getDirectoryUri method
There's no need for the "else" condition. Something like below will be more streamlined.

if($is_true) {
  return 'foo';
}
return 'bar';

Hi @anybody,

I appreciate the assistance in the queues. I've been keeping an eye on anything that looks urgent. Besides the assets:// wrapper, I haven't seen much that has provoked me to jump in. There are some great discussions and work in those issue queues, but for now, I would prefer to keep a close eye on it and avoid additional maintenance burdens. I have some thoughts about refactoring the module into a bundle entity type and possibly allowing content storage along side config storage.

Please continue to contribute through the issue queues and I'm happy to revisit the request at a later date.

Thanks.

Since it seems the MR patch url isn't working correctly (it seems outdated), here's a patch file that applies to both 1.x and 2.x branches. It's the same as the MR.

Patch in #5 solved it for me. I wouldn't think there needs to be a canonical path for encryption profiles anyways.

I've been just ignoring the error for a while and finally decided to see if there was anyone with the same issue. Glad I waited until today.

Any security concerns are handled by the security advisory process → . Also, as mentioned on the module information "This module is definitely not a replacement for full-fledged theming" and standard theme development is recommended for long term stability.

That being said, any concerns with storing the CSS/JS in the database is arguably minimal compared to any other data stored, such as user data, privileged content data, etc. If a user has access to manipulate data in the database, they have greater access to obtain more sensitive information. The permissions to edit via the UI is configured to be "restricted" and therefore there is a warning when granting permissions that there is a security concern with the message "Warning: Give to trusted roles only; this permission has security implications", therefore, any risk is assumed by the site administrator granting such a permission.

Can you encrypt the data that is stored in the DB, sure. You can implement your own hooks such as hook_entity_presave and hook_entity_load and encrypt/decrypt the data stored in the DB. If you are concerned about the risk of the generated CSS/JS files, I will refer back to my first point and suggest standard theme practices. Drupal's CSS/JS aggregation as well as browser loading requires a static file to be available, so there's no other option than to have these saved to the file system upon page load.

pookmish → created an issue.

Thanks for the reference to the Core issue, @el7cosmos. That makes more sense why this issue is happening. It looks like your MR works well for me. I was able to do a full site install with a memory limit of 512MB. To be thorough, I tested with 256MB memory limit. Both your MR and the patch in #7 ran OOM. I like your approach better as well since it maintains proper dependency injection in the service.

Thanks.

Since the above patches required re-rolling to support the latest version of the module, I double check the memory issue. It still occurs and happens with both services. I tried to leave each of the services, but the OOM would still happen.

@el7cosmos this is tough to test, but it seems like others are having similar issues. If you have an installation profile that can install from existing configuration, it should be replicated. Lower your CLI memory limit to something. For my situation, even 512M caused the OOM error.

Using the MR33 I got a warning when the image is first uploaded:
Undefined variable $webp_wanted in Drupal\webp\Controller\ImageStyleDownloadController->deliver() (line 192 of modules/contrib/webp/src/Controller/ImageStyleDownloadController.php

I think it would be better to break out the "if" statement just a little. Since I'm faster with patch files at the moment, I've provided one with an interdiff.

@hswong3i, This sounds like you have something else going on. In the 8.x-2.x version, line 153 is a comment and the only thing added in the commit was adding a hook_preprocess_maintenance_page which works exactly like it's supposed to when using a base installation. You should debug your code first.

Providing a patch for the latest version of migrate_tools.

This issue breaks all Drush commands with these two module. This is a critical issue.

This is really a duplicate of 🐛 "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found PathRedirectImportCommands Postponed: needs info

Providing the patch for 8.x-2.x version

pookmish → created an issue.

Looks like the test changes from #16 were actually implemented in another change.

Rerolling the patch with just the .module change for D10.2.0+

Sufficient, probably. It think of the dependency as a belt and suspenders approach.

pookmish → created an issue.

The provided patch does not fix anything. When using the provided field widget only (not the submodules at all), the classes for the icons in the autocomplete do not match FontAwesome 5 classes. They do however match FontAwesome 6.

Take for example the `drupal` icon: Using FA5 the appropriate classes are 'fab fa-drupal'. But in the autocomplete controller, the brands are prefixed with 'fa-brands'. This matches the FA6 version of the "drupal" icon though.

The good thing for me is that the displayed classes using the included field widget render correctly.

I do believe this module should definitely support the FA6 classes, but also the FA5 classes.

pookmish → changed the visibility of the branch 3406342-support-php-8.2 to hidden.

Patch file provided for anyone that may need it.

pookmish → created an issue.

pookmish → created an issue.

I believe this is outdated now with the 8.x-3.0-rc1 release. I am able to use wildcard force imports without the need for any patch. If anyone can confirm, this issue might be closed.