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

Account created on 7 February 2013, almost 12 years ago
#

Merge Requests

Recent comments

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Patch #54 didn't quite work for me.
Timezone was still not applicable on the front-end (if selected "Use time zones from individual dates").
After debugging I found the missing piece to it.

I have added a $timezone param to renderStartEndWithIsoAttribute(...) function, so it can accept the value from inside viewElements() function call.

Attached a fix based on #54 , which is also re-rolled for 10.3.x branch.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

I have rerolled the patch for Drupal 11.x branch (it is at the tag of 11.0.2 now).
I had to combine patches from #91 + #95, because otherwise was having all kinds of issues mainly related to List type fields (couldn't create these fields on nodes, any entity containing this field type was throwing an error, etc.).

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

I have tested using solution from comment #79 ✨ Make compatible with simple_sitemap 4.0 & domain_entity Fixed and unrelated links are no longer in the sitemaps. Only the ones that belong to the domain.

By removing "Entity URL Generator" generator I was able to make all sitemaps/links work.
E.g. for Domain type sitemaps I have left these generators that work fine:

Then just on the sitemap variants config pick this sitemap type and assign a domain. Works.

Using 3.0.0-beta1 for domain_simple_sitemap and ^4.1 for simple_sitemap

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

This issue seems to have been related to https://www.drupal.org/project/domain_simple_sitemap/issues/3251227 ✨ Make compatible with simple_sitemap 4.0 & domain_entity Fixed , which is already resolved.
domain_simple_sitemap (3.0.0-beta1) works fine now with simple_sitemap (^4.1)

Tested, had no errors.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Have you seen this comment: https://www.drupal.org/project/domain_simple_sitemap/issues/3251227#comm... ✨ Make compatible with simple_sitemap 4.0 & domain_entity Fixed that might fix your problem? It did help me with indexing content by domains properly.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Refactored the patch for CTools 4.1.x-dev version.
This patch is used on a production site and is working as intended.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Added MR !17 on 2.0.x branch with the changes from #25 (without language piece)

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Rerolling for Pathologic 2.0.x branch

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Added MR !126 for the integration fix.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Have the same issue and cannot figure out why it happens..

Have a view block on a page that loads a content block based on exposed filter (with a webform field on it), the view is using AJAX.
After that block is loaded on the page, the webform rendered within that block gets the action as "/views/ajax", while if the webform is simply placed on the page by itself, the action URL will be "/current_page_path"

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Created a merge request based on the patch.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

I have updated the open MR !60 to include the alter hooks from patches #4&5.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

I have tested MR4767 and it works well on the front-end, but the backend is breaking for Media Library widget.

Once you try to insert a media on a node with Media Library form selection widget and use the text search there to find the media file, it redirects you to "/admin/content/media-widget/image" with 403 status.

If the MR patch is removed, it works well again.
Not sure whether the AJAX is not being re-attached to the form elements, but with the MR patch applied the pager for Media Library form still works well. It's just this search box that is giving hard time so far.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Never mind, turned out to be a corrupted project build that missed the file.
File exists in core

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Found a minor issue with the FullDate argument. Views module provides it as "date_fulldate", and not "date_full_date" (for Datetime module it is defined as "datetime_full_date"). Updated a patch with just this change. The rest worked for me - allowed to select granular Views arguments for the Calendar module (version 1.x-dev as of Sep 30, 2023) with SmartDate (version 4.0.0-alpha1) and Drupal Core 9.5.11 .

Have the following patches in place to make things work together:

"drupal/calendar": {
"view_args always contains the current date when using ajax pager: https://www.drupal.org/project/calendar/issues/2858086 πŸ› view_args always contains the current date when using ajax pager Postponed: needs info ": " https://www.drupal.org/files/issues/2022-04-19/calendar-view_args_ajax_f... β†’ ",
"Check argument validity when using getDisplayForGranularity: https://www.drupal.org/project/calendar/issues/3197276 β†’ ": " https://www.drupal.org/files/issues/2022-10-06/calendar-getDisplayForGra... β†’ ",
"Support for Smart Date, other contrib modules: https://www.drupal.org/project/calendar/issues/3177761 β†’ ": " https://www.drupal.org/files/issues/2022-06-13/3177761-6.calendar.Suppor... β†’ "
},
"drupal/smart_date": {
"Support Calendar module: https://www.drupal.org/project/smart_date/issues/3177760 ✨ Support Calendar module Needs work ": " https://www.drupal.org/files/issues/2022-06-13/3177760-5.smart_date.Supp... β†’ "
},

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

Added a patch to allow for setting Tags on subscribers through each webform's config. Single tag or comma-separated list.

πŸ‡ΊπŸ‡ΈUnited States veronicaSeveryn

A new releases has been added to drupal.org project, which now supports Drupal ^8.9|9
It is being used in production on one of the sites (PHP 8.0) and it proved to be operational (RETS system utilized for connection in this case is BRIGHT MLS).

Feel free to test it out and report any issues found.

Production build 0.71.5 2024