πŸ‡ΊπŸ‡ΈUnited States @jmouse888

Account created on 5 August 2007, almost 17 years ago
#

Recent comments

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Will this be merged soon? Trying to upgrade our D9 to D10 and would love to do it without any patch in place. Thank you for your time.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

#6, Can you put a watch on "e" and see what value it has when the header is visible? Or when you scroll up and down? thx.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Generated a patch to change the rootBounds to intersectionRect. I don't know how to do a merge request or even be able to. Someone test this please. Make sure to clear the browser's cache as well as the Drupal cache.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

This is related to the sticky header improperly displayed when the table is out of the viewport bottom. I have an issue open for that. Linked.

Table sticky header appears when table not in viewport πŸ› Table sticky header appears when table not in viewport Fixed

πŸ‡ΊπŸ‡ΈUnited States jmouse888

I'd like to clarify something. When using intersectionObserver, it's recommended to use rootBounds. However, we face a problem with the sticky header <table> tag as it exists within the actual <table> tag and is positioned absolutely at the stickyOffsetTop. This causes the rootBounds.top of the actual table to always be at the stickyOffsetTop position when the table is outside of the bottom of the viewport, triggering the display.

When using intersectionRect for the real table, only the visible area of the table is considered, which does not include the hidden sticky header <table>.

Alternatively, instead of changing to intersectionRect, we can move the sticky header <table> outside of the main <table> tag in HTML. I don't know if this is done by Gin or Claro. I believe most other themes do that, but the pros and cons of doing so is another debate for another day.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Sorry. That #10 patch, while partially working, is not complete. It only addresses the extrasmall dropdowns, not the small ones, or any of the other variables (border size, table drag icon size etc). Also, there is no need to redefine classes as they are already defined in Claro. Simply commenting out the lines in Gin will make the classes fall back to the Claro declarations. Here is a new patch which will comment out all Claro variable calls.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Okay, after fighting with regex for a half hour, finally got a list of variables Gin is calling from other places.

--tabledrag-handle-icon-size
--space-m
--dropbutton-border-size
--dropbutton-small-toggle-size
--dropbutton-extrasmall-toggle-size
--ck-color-toolbar-border
--ck-focus-outer-shadow
--ck-color-text
--ck-color-base-background
--ck-color-image-caption-text
--ck-color-image-caption-background

All of the ck editor variables are loading fine on the node edit interface, so they are good.

the 5 variables from Claro are not getting their values (most likely the PostCSS issue #9 pointed out). I'm comparing these values set in RC5 and generating a patch.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Yes I do have Claro installed. It's at 9.5.10.

Here is the error in the browser. Same error on the "--dropbutton-border-size". Nothing in the console.

Thanks for the help.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

We ran into the same issue. Yes, the query should be rewritten to accommodate both uuid (charvar) and id (int). As a short-term solution, I just converted (with the CAST operator "::") the nid from the {node} table from int to charvar so the "=" operator will work as intended.

around line 75 in src/Plugin/views/filter/FancyFileDeleteOrphanFileFilter.php

from:
AS fu ON (fm.fid = fu.fid) LEFT OUTER JOIN {node} AS n ON (fu.id = n.nid)

to:
AS fu ON (fm.fid = fu.fid) LEFT OUTER JOIN {node} AS n ON (fu.id = n.nid::character varying)

I also created a patch. This will not resolve the uuid orphan query. However, with the majority of the file attached to nodes on our site, this will work fine for the time being.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Somehow I'm getting this error while using unique on Entity Reference fields. Two content types were set up with fields using Entity Reference and were working for the past few months on my devel site. Today all of the sudden, the unique constrain stopped working and I'm getting this (or similar) error in the status log. User are able to create new content with the same field value set to be unique. My specific error is "Warning: Illegal string offset 'target_id' in unique_field_ajax_validate_unique() (line 572 of ...../modules/contrib/unique_field_ajax/unique_field_ajax.module)"

Running D9.5.9 and Unique Field Ajax 2.1.2

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Three and a half years later, still having the same problem. Running Drupal 9.5.8 and bg_image_formatter 8.x-1.16,

However, some how it's only happening our front page. All internal pages are rendering the inline styles just fine, even with authenticated users. Only thing different for the front page is it's using a different page--front.html.twig. The rest of the site is using page.html.twig

From browser source code, BigPipe are loaded for both page templates. Don't know why it will work with one but not the other.

Uninstalled BigPipe and everything is working.

May be if I trace the difference between the two page templates may result some clue. Will investigate further down this route.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

Confirmed Editor Advanced Link 2.1.1 is working with Drupal 9.5.7.

πŸ‡ΊπŸ‡ΈUnited States jmouse888

I can confirm the same error after Drupal 9.5.6 upgrade. (TypeError.... formView is null)

Production build 0.69.0 2024