🇫🇷France @flocondetoile

flocondetoile → created an issue.

flocondetoile → created an issue.

> However, the download link in the status message doesn't work.

I guess that if the download link doesn't work, it's because the file has been already downloaded (and this is what your patch shows as "fix"). And as we delete the file once it has been downloaded, then the link is not relevant anymore. It's not really a bug, it's a feature ! So I think then, if the file is automaticcaly downloaded (or even manually), then the link/sentence about the download should be replaced by a sentence as "the file has been downloaded. Check your download directory.".

I think we must keep the feature which delete the file once downloaded, as we don't need to keep it anymore on the server.

Why have you added the file_url_generator service as argurment for the entity_export_csv.manager service ? It's not needed (and not used in the manager).

I wonder if the file_url_generator should be injected into the FileExport Class instead of the FieldTypeExportBase Class. Does the file_url_generator could be used by other field type plugin than the FileExport plugin ? Let's it as actually for now.

And as we change the constructor of the FieldTypeExportBase class, shouldn't we trigger a cache rebuild by implementing an empty hook_update_N() ?

Tests are failing. So set as Need Work.

Tests exist yet. They "only" need to be fixed.

Same error here and patch #6 fix the issue

So help in 📌 Automated Drupal 10 compatibility fixes Needs review

reroll for 1.11.0 version

flocondetoile → created an issue.

flocondetoile → created an issue.

This one should pass

I didn't succeed in reproduce this issue. Would try this patch to see if this resolve the issue in your use case.

Thanks. Committed.

rerolled patch

Thanks but you don't solve the root cause. You just hide the error.

flocondetoile → created an issue.

Whaou. That was quick! Thanks.

support for polarArea was added in ✨ Support Polar Area for chart.js ? Fixed

flocondetoile → created an issue.

Also allow micro_site admins to update / delete unpublished node assigned to their site.

flocondetoile → created an issue.

It will be a big refactoring.

It's not only the excessive usage of "access adminsitration pages", but the access control on collection / entities of a self_evaluation has not been done to allow an owner of a self_evaluation entity to edit all the composants of the self_evaluation.

Also added a new permission allowing to view only form IDs

flocondetoile → created an issue.

Also, why use \Drupal::moduleHandler()->invokeAll().
\Drupal::moduleHandler()->alter() looks the right way to perform this no.

And if we use the module_handler service, we need to inject it in the manager.

Hello. Why not let the logBlockedSubmission() in the native condition and just add an hook if the protection is trigerred ?

flocondetoile → created an issue.

Hello @netsliver. I gave you maintener rights on the project. Welcome !

I wonder even why I wrote this eventsubscriber.
May be because when i wrote this, micro_taxonomy module (and micro_node which have same eventsubscriber) didn't exist yet.

The best is to remove this I think

Looks like this is generated by the module conditional_fields

conditional_fields_entity_type_alter(Array, NULL, NULL) (Line: 539)

Hi, implementing this hook means the alias is saved / updated twice if the entity is saved from its form. The first time by the widget element, and the second time by this hook.

What prevent you to run
Drupal::service('micro_path.pathauto_generator')->updateEntitySiteAlias($entity, $site_id, 'update');
just after programmatically call your node->save() ?

Thanks everyone

Hello @gombi. Are you running already Micro Menu with the patch on Drupal 10 project ?

flocondetoile → created an issue.

Move the protected static $modules declaration to BaseTest.

MR1 slightly changed

flocondetoile → created an issue.

Tests looks fine for D9 and D10.

Test seems need to be updated to be able to run on gitlab-ci. This should be another issue.

Add a .gitlab-ci.yml for new testing on gitlab.

Patch was form #14 but the patch miss fix present in MR3.

Rework a new patch based on MR3. Dropping the resizable part for the css per micro site. And so no dependencies for a such minor feature.

Making this change will break existing installations. Can you please include a migration that assigns this new permission to all existing users that have the "administer users" permission?

Not sure patch #2 will break anything. Anyway, site administrators still get access to PRLP settings.

And in my case, this patch is useful because I don't want users with the permission "administer users" to be able to manage PRLP Settings. And in my case, when i give the permission "adminsiter users" I didn't want to give them the permision to manage PRLP settings. So In my mind patch #2 should be committed, not #5 which ensure that an unwanted situation is still present.

Otherwise RTBC++ (#2 or #5)

Same issue here. Users with no permissions for the first link get an access denied. MR 6100 fix the issue

Closed as duplicate of 📌 [Micro Site] Automated Drupal 10 compatibility fixes Needs work

drupal.org unpublished them form the project page because they don't have yet a release compatible with D10. But they are still available here : https://www.drupal.org/project/micro_site/releases →

Hello @energee

Thanks for your module. It's really useful. I wonder if you need help for tagging a new release (because a lack of time I suppose) ? If it's the case I can happily do it for you (I just need the right access to the repository).

Yes you're right. Mine are always broken. I investigate how the reverse proxy is configured (they are managed by IT, but theorically they only dispatch requests whithout managing dynamic/static assets), and I have an HAProxy in front of the apache web server.

From #6

Still not sure if this is an issue with Drupal, Symfony or dompdf though... It does not appear to originate from this module.

Or may be the stack on the server (apache / nginx / haproxy, etc.)

retitling

Hello,

Same error here with Drupal 10.1.6 and Entity Print 2.13, but with the print engine DomPDF. And during a cron job launched via drush to generate PDFs (which don't have a session).

/** @var \Drupal\Core\StreamWrapper\StreamWrapperManagerInterface $stream_wrapper */
$stream_wrapper = \Drupal::service('stream_wrapper_manager');
$print_engine = \Drupal::service('plugin.manager.entity_print.print_engine')->createSelectedInstance('pdf');
$print_builder = \Drupal::service('entity_print.print_builder');
$billfile_uri = $print_builder->savePrintable($orders, $print_engine, 'private', $stream_wrapper->getTarget($file_destination . $bill_filename));

The stack trace

Trace :
#0 /var/www/xxx/web/modules/contrib/entity_print/src/Plugin/EntityPrint/PrintEngine/DomPdf.php(285): Symfony\Component\HttpFoundation\Request->getSession() 
#1 /var/www/xxx/web/modules/contrib/entity_print/src/Plugin/EntityPrint/PrintEngine/DomPdf.php(238): Drupal\entity_print\Plugin\EntityPrint\PrintEngine\DomPdf->setupHttpContext() 
#2 /var/www/xxx/web/modules/contrib/entity_print/src/Plugin/EntityPrint/PrintEngine/DomPdf.php(228): Drupal\entity_print\Plugin\EntityPrint\PrintEngine\DomPdf->doRender() 
#3 /var/www/xxxx/web/modules/contrib/entity_print/src/PrintBuilder.php(100): Drupal\entity_print\Plugin\EntityPrint\PrintEngine\DomPdf->getBlob() 
#4 /var/www/xxx/web/modules/custom/xxx_commerce/src/SalesJournalGenerator.php(372): Drupal\entity_print\PrintBuilder->savePrintable() 
#5 /var/www/xxx/web/modules/custom/xxx_commerce/xxx_commerce.module(793): Drupal\xxx_commerce\SalesJournalGenerator->generateSalesJournal() 
#6 /var/www/xxx/web/core/lib/Drupal/Core/Cron.php(335): xxx_commerce_cron() 

attached a patch with same fix for DomPdf print engine

Looks like yes. In maintenance mode, on a project with a lot of small files css/files, the page sent about a hundred request to the server, behind a reverse proxy, this last respond with 502 bad request (because the high number of simultaneous request done).

Also PDF are well rendered on local instance and on a dev instance located on a simple server.
PDFs are broken for preprod and production sites which are behind a reverse proxy.

Same issue here. Since I upgrade Drupal Core to 10.1.6 (from 9.5.11) CSS are not loaded anymore by entity print when printing node or commerce_order to a PDF (with DomPDF). Hotfix in #5 doesn't resolved the issue.