🇬🇧United Kingdom @jacobupal

jacobupal → created an issue.

I have AJAX errors in 2024 and the various interactions which cause this seem to be: VBO, Pagination and Exposed Filters

Here's the console error when using exposed filters:

An AJAX HTTP error occurred.
HTTP Result Code: 404
Debugging information follows.
Path: /views/ajax?field_question_value=&title=&flagged=All&status=0&flagged_1=0&uid=&field_question_triage_value_op=empty&field_question_triage_value=All&ajax_form=1
StatusText: Not Found
ResponseText: {"message":""}',
name: "AjaxError",
stack: "
  @[webroot]/core/misc/ajax.js?v=10.3.1:196:32
  @[webroot]/core/misc/ajax.js?v=10.3.1:1921:3
  "

By the looks of it, the request URL probably needs cleaning up to work?

Note: I haven't tested this yet but I can see the line that seeks to address this in version 1.0.1 - looking forward to trying it out.

Update: Adding "aside" and the other similar elements to the "blocklist" list seems to fix this... I think was mistaken into thinking this was applying to divs too, because of how I was using templates, but it turns out the problematic element in that situation was actually a <section> element.

I'd suggest adding these html elements to the "blocklist" list: <section>, <aside>, <figure>, <article>, <nav>, <header>, <footer>, <main>

I don't think all of those are necessarily good to use in content, but given there is no way to add this support without patching the module I think allowing these semantic elements to function when they are used can only be a good thing.

It also feels like <mark> would fit in the "allowlist" list.

jacobupal → created an issue.

I can see what postcss is trying to do...

In situations where you've nested a list of selectors inside another list of of selectors, and you want to support browsers that aren't compatible with css nesting, but which are compatible with the the ":is()" selector, then ":is()" can be an efficient way to provide something equivalent to the nesting.

For example, this (with nesting):

article,
aside,
section,
div{
  p,
  table,
  img,
  figure{
    width:100%;
  }
}

...is equivalent to this (without nesting, aka pre-2024):

:is(article, aside, section, div) :is(p,table,img,figure){
    width:100%;
}

.... which is far fewer characters than than this (without nesting or the use of :is(), aka pre-2021):

article p,
article table,
article img,
article figure,
aside p,
aside table,
aside img,
aside figure,
section p,
section table,
section img,
section figure,
div p,
div table,
div img,
div figure{
  width:100%;
}

All three are perfectly correct CSS... but from the looks of it, postcss is clearly not smart enough to properly recognise all situations where :is() is not necessary.

If there's no other ways to tweak the processing (e.g. unwrapping any :is() selector which doesn't contain a comma) then you're just choosing between the efficiency of allowing the use of :is() for more complicated nested structures, with the side-effect of it sometimes being used unnecessarily, or going without :is() in appropriate situations in return for potentially longer, but more backwards compatible css, and no superfluous :is() selectors.

jacobupal → created an issue.

I did try the dev version, it works correctly, as shown.

I will try in the content blocks now... yep it works exactly the same way as it does for content types!

@ressa No problemmo! In commit number2036524 on 4/2/2019 I see fields without the index numbers appearing in the example given within src/Plugin/migrate/source/CSV.php(before that a example yaml isn't provided) - and that is the beginning of the 8.x-3.x branch

Going back to the commit made on on the dev branch on March 12th 2018 in migrate_source_csv.source.schema.yml, column_names goes from sequence to ignore - so that seems to be where the change actually happened. But lets say version 2 was where the old method was used, and 3.x is where the new method is used.

I just tried this again. This time with a clean install of Drupal 10.0.4 using drupalpod, with ckeditor_insert_blocks 1.0.0.

To reproduce the error, (and demonstrate the fix) this is exactly what I did:

1. Install Drupal 10.0.4 using drupalpod, with ckeditor_insert_blocks 1.0.0.

Make sure the fix for this issue hasn't accidentally been included already (I had to manually remove it, because drupalpod installs version1.x-dev by default, and in that branch the recommended code has already been added)

To ensure the right version is being tested, this should not appear in the code when testing:

  static get requires() {
    return [ContextualBalloon];
  }

1. Make a new text-format - The preconfigured text-formats (html, full_html, etc) will not trigger the error because they have some other plugins enabled by default - You will need to create a new text format where you will see that only "bold" "italic" and "Headings" are enabled, but no other buttons, or filters.

2. Add the ckeditor_insert_blocks button and filter.

3. Edit a piece of content with this new text format.

4. The toolbar will not load.

5. Add the following to the code:

  static get requires() {
    return [ContextualBalloon];
  }

6. Refresh and you will see it works again.

I've attached a video showing the change which occurs with or without the additional code.

So I think we can call this "Fixed".

Good to know!

Problem/Motivation

The module styling uses CSS variables for styling which are usually provided by gin

Steps to reproduce

Choose a theme without styling for dialog boxes
The dialog box will be unstyled

Proposed resolution

- provide fall-backs to gin variables used

/* Borrowed from CyborgTranslate's css/disclaimer.css which had to deal with the same problem of the core modal using gin/admin stylings but gin not being available to visitors. */
.dismissableblocks-disclaimer-modal.ui-widget.ui-front {
  z-index: 1000;
  border: solid black 3px !important;
  background: white;
  --ct-gin-border-color-layer: var(--gin-border-color-layer, rgba(0, 0, 0, 0.08));
  --ct-gin-border-m: var(--gin-border-m, .5rem);
  --ct-gin-bg-app: var(--gin-bg-app, rgb(249, 251, 248)); }
  .dismissableblocks-disclaimer-modal.ui-widget.ui-front .ui-dialog .ui-dialog-titlebar {
    line-height: 1.2;
    padding: 1rem 1.5rem;
    background: #1b1b1d;
    border: 0 none;
    border-radius: 0;
    position: relative; }
  .dismissableblocks-disclaimer-modal.ui-widget.ui-front .ui-dialog .ui-widget-content.ui-dialog-content {
    padding-left: 1.5rem;
    padding-right: 1.5rem;
    padding-top: .5rem;
    padding-bottom: .25rem; }
  .dismissableblocks-disclaimer-modal.ui-widget.ui-front .ui-dialog .ui-widget-content.ui-dialog-buttonpane {
    padding: .75rem 1.5rem;
    border-top: 1px solid var(--ct-gin-border-color-layer);
    border-bottom-left-radius: var(--ct-gin-border-m);
    border-bottom-right-radius: var(--ct-gin-border-m);

Remaining tasks

- css has already been added
- review

User interface changes

- prettier

API changes

- changes to dismiss_and_remember.css

Data model changes

N/A

The example YAML referred to a feature in a previous version of the module where index numbers were used for selecting columns to be used by the migration. This is no longer the case so I updated the guidance accordingly.

Added a solution for entity types other than "node"

Got it. It's a shame that such a fix would prevent my workaround!

jacobupal → created an issue.

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

Would that dependency force the feeds_item field to be created when you import a config, or just prevent the import?

Ooh thanks for approving, and sure that'd be great!

I don't know if this was the problem for OP, but I had this same error when I created the feed type by importing a config with drush.

When you you create a feed type manually, it creates the feed_item field on the content type.

However, importing the config with drush doesn't do anything to the content type.

To resolve this I went to the settings page for the problematic feed type and just hit save, this seems to have generated the field and fixed the problem. The importer was then able to run successfully.

jacobupal → created an issue.

jacobupal → created an issue.

jacobupal → created an issue.

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

jacobupal → created an issue.

Here's some css which I think improves the appearance of the "Flexible by design" section at narrower screen sizes:

/* Keeps the gaps between the flexbox items, not at the end */
.grid-list{
  justify-content: space-between;
}

/* Display each item as a grid (when narrower than 1400px)  */
.grid-list__item  {
  display: grid;
  
  /*  Define the grid geometry  */
  grid-template-columns: auto 1fr;
  grid-template-rows: 1fr 1fr;
  gap: 0 1.5rem;
  
  /*  Get rid of the 33% width */
  min-width: calc(50% - 1.5rem);
  
  @media (min-width: 1400px){
      /*  Return to the default appearance above 1400px */
      display: initial;
      min-width: calc(25% - 1.5rem);
  }
}

/* Define the layout of items when displayed as a grid */

.grid-list__text{
  grid-column: span 2;
}

.grid-list__heading{
  margin-top:unset;
  width: 100%;
  align-self: end;
    @media (min-width: 1200px){
      margin-top: 2rem;
  }
}

.grid-list__icon{
  align-self: end;
  img{
    max-width:min-content;
  }
}

(You can test this using a browser extension like Stylus)

What it does:

• Keeps gaps between the flex-box items, not at the end, so that the last item in a row always lines up with the right-hand margin.
• Displays each item as a grid (when narrower than 1400px)
• Define the grid geometry
• Get rid of the 33% width
• Return to the default appearance above 1400px
• Define the layout of items when displayed as a grid

Here's how it looks after the change at under 1024px and under 1400px:

@shderuiter Nice! I didn't know about that... It definitely would be a better way to do it when writing your own HTML.

That said, when incorporating it into the editor I don't know how the "name" values should be allocated, or how we would ensure that names are unique to each intended group.

Perhaps having users choose a name and giving them some instruction when choosing a name would do it, but I do think that'd feel clunky, and far from mistake-proof.

I also wouldn't be able to insert an identical template for this purpose if the name has to be unique to each group...

I assume this is possible too but I can't find any examples... Here's as far as I've gotten trying to do it with title:

Event:
VBO: Confirm form Build
Action:
Form: Add text field
field name: set_title

This successfully places an input form after the action is clicked, and before the operation is executed.

2nd part:

Event:
VBO: Execute
Actions:
VBO: Get Config Value
config key: set_title
name of token: get_title
Entity: Set Field Value
field name: title

This second part however is not working for me. I can't work out how to pass the form input into the execution stage. It sounds like the "vbo: get config value" action is meant to do it but no dice so far:

VBO:Get Configuration Value description: "Get a configuration value from the action of the bulk operation and store it as a token. This template supports the usage of tokens. Please refer to the token chapter in the ECA Guide, and if you install and enable the token module, you will find a link to the token browser right below the property panel, which shows you all available tokens."

Config key:
The config key, for example message_text. This may also be the machine name of a custom form field. Leave empty to use the whole config. Please note: This action only works upon the event VBO: Execute Views bulk operation.

jacobupal → created an issue.

I've played around trying to do the above but it's a little bit beyond me... this would be a really useful example/template if anyone is up to it.

I updated the summary to match the issue template, as this solved my problem too.

I'm getting this error in a more convoluted scenario; I have three different types of comment in a fieldgroup, rendering on a page where there are also editable fields. I'm pleased to say the proposed change also handled my case and I stopped receiving needless error messages.

Comment fields do not need to have default values and this patch seems to handle the situation well.

Updated the issue branch to make it merge-able again since conflicts arising from https://www.drupal.org/project/drupal/issues/3396165 📌 [meta] Convert all core plugin types to attribute discovery Postponed

Just to illustrate, I performed the same 3 steps and have screenshot what happens before and after this proposed change.

The steps:

1. User "jacob" creates the new article.
2. User "clare" makes a change to the article.
3. User "admin" performs a replacement which affects the article.

This first image compares two screenshots; before and after. It can be seen that there is no change to the "author" from this proposal.

However, when viewing revision history there is a difference.

Before the patch/MR, we can see the latest is revision is incorrectly attributed to "clare":

After the patch/MR we can see the latest revision is properly attributed to "admin":

I think you might have misunderstood (forgive me if not!). This proposal would not make the person running the replacements the author of the piece itself (the "uid") instead I'm proposing that the "revision_uid" value (not "uid") in the new revision should reflect who ran the replacement.

In your example, the author of piece would remain whatever it was before the replacement, but when reading through the revision history, the change would be now attributed to the administrator who ran the replacement, this would only be visible by users who can read the revision history. Or if for example you have made the revision user visible in your theme using some view/twig like "Created on [created] by [uid] and last updated on [changed] by [revision_uid]".

With the current behavior: if I make a normal change to an article, and a new revision is made, that change/revision is always attributed to me by default. But then, if somebody runs a bunch of replacements after me, using this module, those changes are now attributed to me too, even though I have nothing to do with them. Those new revisions are not my work, and if somebody asks me why I made those changes I won't have anything to tell them.

I can't really think of a situation where this proposal shouldn't be the default, because that is who made this change. Attributing changes/revisions to people who didn't make those changes seems like a bug to me...

I can see a situation where you might like the option want to force "revision_uid" to be some generic user and call it "bulk changes" or something, however I think that'd be a different proposal/issue.

xjm → credited jacobupal → .

jacobupal → created an issue.

jacobupal → created an issue.

jacobupal → created an issue.

I've been playing round with the CSS for the same reason and it seems there's no way of adding a color overlay to an image without writing js or changing the markup... the issue is that img tags are self-closing so you can't use pseudo elements.

What did work was adding outlines though which I think helps at least show which version version of the image was deleted and which was added.

You should be able to add this CSS to your theme for the same result:

del.diffimg img{
  outline: 2px dashed red;
  outline-offset: -3px;
}

ins.diffimg img{
  outline: 2px solid limegreen;
  outline-offset: -3px;
}

I can confirm now that on a clean install of 10.3.x using DrupalPod that toggling twig debugging (through the UI/config) does indeed result in that extra space appearing and disappearing.

So the problem, as it exists now, is not with glossify but with the twig debugging implementation, just as you suggested @tgoeg

Any line-break issues I am able to reproduce now while the twig-debugging is turned are associated with my custom template, so again, not strictly glossify's problem.

I do think that there initially factors other than twig-debugging at-play earlier on in the timeline - both because in @mjgruta'a OP we can see their devtools in the screenshot, and there's no debugging markup there, and because they to have been saying that when they deleted the empty line (which is part of Drupal's coding standards) the white-space went away, which wouldn't make sense if the cause had always been twig debugging.

Also, that same solution just over 2 months later, presumably with a different drupal version, didn't work for me in 2023.

I have the impression that some thing(s) outside of the module, in twig or in core, have been changed or improved since this issue was created, leading to some of our confusion. And it'd be worth keeping an eye on anything in core which might affect this.

If this does come back again for anybody else who ends up down the same path as me, I can say that the whitespace went away when I did any of the following:

• Deleted my custom template and fell back to the default glossify-link.html.twig
• Made sure my custom glossify-link.html.twig only contained nested elements.
• Made sure my custom glossify-link.html.twig had a wrapper element with no whitespace between the nested elements.
• Used the twig spaceless filter to achieve something similar. (I know the spaceless filter is due to be deprecated, but I wanted to see how it works. Turns out it only worked on spaces introduced by my template - the spaces introduced by twig debugging mode were untouched which makes sense. )
• As a last resort used javascript to remove the unwanted whitespace.

But if it's all working now, maybe the issue is resolved and can be closed?

Hey @robbiehobby does your re-roll in #79 include your proposed change in #78?

john cook → credited jacobupal → .

john cook → credited jacobupal → .

john cook → credited jacobupal → .

I monitored "When Designers code - UX Paper Cuts at GitLab" - Room 2

I monitored "Designing for Low Literacy: Enhancing Accessibility and Understanding" - Room 2

I monitored "70 good reasons for a code refactoring"

I monitored "Local development for environments for Drupal with DDEV"

Here is a screenshot of before the changes.

This needs to be reviewed by somebody who knows fields because now the patches have been re-rolled and turned into a merge request we can't actually confirm that the the types and identifiers present in the annotation are correct or correspond correctly with the associated field types.

I'm also removing the novice tag, as this has moved far beyond novice!

Our table is working on this!

We're working on this on our contrib table

^^ Not anymore, our bad @ultimike! We thought the 'team' meant the whole mentoring team & newbies. Good luck!

We're working on this in our contrib table.

Updated the proposed resolution with regards to providing more settings.

The changed the snippet is describing the default values not possible options.

Removed novice tag as it wouldn't be for a novice to split this into separate issues and/or meta issues.

Removing novice tag as the next steps require some specialist expertise.

I've just tried this out and while [node:body-smart-trim] alone will work, when I use it as a meta tag description [node:body-smart-trim:160] i.e. including a max-length value, it does not. The page simply loads without the appropriate meta tag present. Presumably because "[node:body-smart-trim:160]" could not be found.

So two questions:

1. Am I using the token correctly?
2. If I can't enter a character limit, what the default character limit being used?

Ok, my bad... Didn't realise this had been fixed elsewhere, just not released yet.

jacobupal → created an issue.

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

I'm having this same issue, in addition to duplicates of the same message (presumably because it is somehow requested more than once, perhaps due to views or some such)... looking forward to testing this patch on alpha5

It works for me, as they say so I think it's ready for review!

I had a very similar situation, but it was removing the Media Embed icon from the toolbar which fixed the situation rather than the Media Resize filter (which didn't solve it) so the problem may be somewhere in the core Media module.

jacobupal → created an issue.

It has been included so that it can be used in the new navigation module.

Even if its discouraged, CDN does at least work, and isn't so easily broken by changes in Core, so I wouldn't write it off just yet. But if you can successfully load it from Core and that works awesome! But maybe that's getting ahead of ourselves.

On how to proceed:

• Maybe a new branch with starter-twig and folders for this sub-module included, I'd maybe call it "JS Toggletips" or similar (is there any need to say which framework is being used in the naming?)
• For now could we make it a fourth option in the tooltip style selection? Does the main module make it easy for a submodule to add a fourth option
• Include Floating-UI in the submodule, via CDN or loading it via core, whichever works the soonest
• Then we get to making it!