#CSS

If a new variable is being added think it needs to be mentioned in the IS. But is that for sure the only way? By doing a twig template change we will need a CR as this fix won't hit contrib or custom themes. Ideally if possible if this can be determined before twig that would be best.

Fixed, hence closing this issue.

Fixed, hence closing this issue.

Automatically closed - issue fixed for 2 weeks with no activity.

Please add steps to reproduce this issue and screenshot for reference.

Version Drupal 10.3
SShop 8.x-1.x-dev

Thanks, yes csslint is not run in GitLab CI, we have Stylelint instead. Thanks for the tidy-up.

I can't reproduce this issue. The custom CSS is just loading fine for me on Drupal 11.2 with optimization turned on or off, both are working as expected.

Can you please provide detailed steps on how to reproduce this on a vanilla fresh installation of Drupal?

@daniel korte I'm not following your extra observation in #5 either. The exception that you provide is independent of the minify setting and only occurs if the library setting has not proprocessing property defined. Could you please re-check and clarify?

Changing to latest version when this was closed.

Automatically closed - issue fixed for 2 weeks with no activity.

I ran into this problem in Drupal 11.2.0 and 11.2.1. There is a PHP error "Exception: Only file CSS assets with preprocessing enabled can be optimized. in Drupal\Core\Asset\CssOptimizer->optimize() (line 46 of /code/web/core/lib/Drupal/Core/Asset/CssOptimizer.php)." because gin-custom.css has minify: false. Drupal 11.2.1 added code to ignore files with minify: true ( 🐛 Website error Exception: "Only file CSS assets can be optimized" Active ). Since public://gin-custom.css may not be a local file it can’t be processed. Maybe it makes sense to set this to external too?

daniel korte → made their first commit to this issue’s fork.

xjm → credited catch → .

xjm → credited effulgentsia → .

xjm → credited joelpittet → .

xjm → credited lauriii → .

Crediting triage as per #13.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I tried to find a solution to exclude eca and the bpmn_io modeller from using gin_everwhyere and as far as I understood shouldn't the bpmn io modeller use gin_everywhere.

When we take a look into gin_everywhere_gin_content_form_routes_alter

function gin_everywhere_gin_content_form_routes_alter(array &$routes) {
  $routes = [];
  foreach (\Drupal::entityTypeManager()->getDefinitions() as $entity_type_id => $entity_type) {
    if ($entity_type->getGroup() == 'content') {
      $routes[] = "entity.$entity_type_id.create_form";
      $routes[] = "entity.$entity_type_id.edit_form";
      $routes[] = "entity.$entity_type_id.override_form";
      $routes[] = "$entity_type_id.add";
      $routes[] = "entity.$entity_type_id.add_form";
      $routes[] = "entity.$entity_type_id.revision";
      $routes[] = "entity.$entity_type_id.content_translation_add";
    }
  }

  // Extra routes that does not fit the pattern.
  $routes[] = 'block_content.add_page';
  $routes[] = 'block_content.add_form';
  $routes[] = 'entity.block_content.canonical';
  $routes[] = 'entity.media.canonical';
  $routes[] = 'entity.menu.add_link_form';
  $routes[] = 'entity.menu_link_content.canonical';
}

When iterating through the entity type definitions we can see that the entity type eca as well as eca_model are both of type of a configuration entity, so they don't appear in the $routes[] array.
So far so good.

Why does gin_everywhere appear on bpmn_io modeller?

Lets take a look at the paths and routes:

When using admin/config/workflow/eca/add (eca.add) we get redirected to /admin/config/workflow/eca/add/bpmn-io (bpmn_io.add) which is no entity, so therefore this route will not be included into the $route array.

But when checking for those two routes in gin_everywhere_form_alter with

  if (\Drupal::routeMatch()->getRouteName() == 'entity.eca.edit_form' || \Drupal::routeMatch()->getRouteName() == 'bpmn_io.add') {
    return;
  }

the function return happens and the gets stopped at this point.
But even if the check for the routes would pass, the hook is stopped by

  // Make sure we are on a gin form.
  if (!\Drupal::classResolver(GinContentFormHelper::class)->isContentForm($form, $form_state, $form_id)) {
    return;
  }

but gin_everywhere is still shown in the bpmn_io modeller and I'm not sure in which direction to take further investigation.

If you could give me some advise, it would be highly appreciated :)

gitlab-ci is the successor, I don't believe this is relevant (cleaning up issues I was following)

Automatically closed - issue fixed for 2 weeks with no activity.