I think I'm also seeing this issue in possibly a slightly different way. The issue I'm seeing is with a non-recurring multi day event coinciding with a recurring event, but only from the second recursion onwards.
In this scenario, the vertical alignment of the multi day event displays in the incorrect position on the coinciding days.
To re-create:
1) Create a multi day event which does not recur. Eg: 1st December 2024 to 8th December 2024
2) Create a single day event which recurs, and the start date is in the previous week. Eg: 27th November 2024, recurring weekly.
When viewing the second instance of (2) on the 4th December 2024, the single day event shows first and the multi day event shows second, breaking the layout of the multi day event.
Commenting out the code as mentioned in #7 and #8 resolves this layout example issue, but I don't think it is the solution, as more complex examples than described here still result in incorrect layout of multi day events.
I think I may be able to offer a bit more on this, though not entirely sure if it's the same as the opening post.
If you add a view that is of type page, and it has a contextual filter in the url, I can't see a way to get a go back link to appear on this.
As an example, a view which lists content which is assigned to that user; lets say articles:
user/*/articles
Where * is the wildcard/contextual filter for the user id.
iancawthorne → created an issue.
I don't think that is the problem I'm describing @ivnish.
The issue is the js is trying to select the username using ".comment__author a", but when the username is not a hyperlink, it is in a "span" tag instead of an "a" tag. I think only the js needs to be updated. The form settings don't need to be touched.
I'm unsure how best to rewrite the js to cater for this scenario.
iancawthorne → created an issue.
Have you added the filters for start and end date so only the currently viewed month is queried? I found without this, as soon as there were 40 or so items to show across the entire calendar, load times were noticeably slow.
There's some documentation here under #IMPORTANT:
https://www.drupal.org/docs/contributed-modules/calendar-view/recurring-... →
I can confirm the patch resolves the issue for me.
Yes, I can confirm that is the case for me too. Works on create pages on 2.1.3, but not on 2.1.4.
iancawthorne → created an issue.
iancawthorne → created an issue.
@ptmkenny I can see the patch at #63 is a lot less lines of code than others. However, up until needing to upgrade from Drupal 10.1.x to 10.2.x, I've been using the patch at #21. If you take out the test lines for that patch, you are left with a two liner, which as far as I can tell does the same as patch #63 but in a very slightly different way.
I'm still not sure what you mean by all cases for user roles though?
@ptmkenny Can you clarify on the [quote]inverts the visibility of the roles in all cases[/quote] part?
From my testing, I update a blocks visibility and did a config export. Only the user role visibility changed in that config export, as expected. No config changed for negating visibility was negated for any of the other conditions, such as by content type, by page or by vocabulary etc.
Are you talking about a different scenario which I'm missing?
The patch at #63 works great on 10.2.x.
Is there a patch for 10.2.x which works on this thread?
I've tried #53, which will apply, but as mentioned in #58, saving the block does not update the negate value. The patches at #43, #46 and #60 will not apply to 10.2.6.
I gave this patch a test, but I think it's probably outdated given it's 3.5 years of no activity. It looks like the gin theme has a similar, but different issue in the previewer iframe doesn't load up when the preview button is clicked.
It seems to be fine on any other admin themes I've tried; claro, mediteran etc.
iancawthorne → created an issue.
A further and more positive update... ignore #13 (unless you have problems)... I found out I needed to completely remove the previous ckeditor4 editor from any text formats. Then apply the patch. Then add ckeditor5 to the text formats.
The patch applies cleanly and from my testing, I can successfully add, edit and use tooltips. +1 for this patch to be committed please.
Thanks @stefank. I can apply the patch from #11 and #12 cleanly.
However, when I go to a configure url for a text format which uses a ckeditor, I get the following php error:
Error: Call to undefined function Drupal\ckeditor_tippy\Plugin\CKEditorPlugin\drupal_get_path() in Drupal\ckeditor_tippy\Plugin\CKEditorPlugin\DrupalImageTippyTooltip->getFile() (line 53 of modules/contrib/ckeditor_tippy/src/Plugin/CKEditorPlugin/DrupalImageTippyTooltip.php).
Attached is what I'm seeing with the version set to 1.0.8 or 1.0.x with composer and using cweagans/composer-patches
Which version of the module is the patch for @stefank? I can't get it to apply to 1.0.8.
Just wondering where things stood with this issue? I've tried applying the patch with no success in seeing tippy working in ckeditor 5.
I'm using the patch at #98 with "3.0.x-dev@dev" and the library at #88 but am still finding that when going back into edit a page, the anchors have jumped to the end of the paragraph.
I'm still finding this is an issue in Drupal 10. Attached is a re-rolled patch against 10.1.
@reenaraghavan which version of the module does is your patch for? I can't get it to apply to 1.0 or 1.x-dev.
I've tested the patch at #6 and can confirm this resolves the issues I highlighted at post #3.
I have tried this patch with the site running on Drupal 10. There look to be issues:
1) Tooltips do not load and I see javascript errors in the browser console:
Uncaught TypeError: Cannot read properties of undefined (reading 'applyStyles')
Uncaught ReferenceError: tippy is not defined
2) Rich text editors (using contrib ckeditor4 rather than core ckeditor5) do not load when javascript aggregation is enabled. They do however load ok when javascript aggregation is disabled.
@maskedjellybean I've just given it a try, but if the view is expected to return results with no filters applied, when the reset button is clicked, ajax does fire, but the view shows the empty text instead of the expected results.
If you need to get rid of
tags add them to core filter Limit allowed HTML tag and correct faulty HTML.
It is not possible to remove
tags from the core filter Limit allowed HTML tags and correct faulty HTML in ckeditor 5.
I have the same use case as the opening post where there is a heading that requires formatting with bold or italic, but the text format should not allow heading or paragraph tags. It looks like this patch does exactly as required.
I would add a +1 for this ticket being re opened.
Just stumbled on this issue on one of our Drupal sites and wondering if this can be progressed and committed?
Reviewed and works. +1 for committing this patch please!
Is that really works as designed? There could be any number of matches against words which would need white listing. This makes this module unusable.
iancawthorne → created an issue.