🇺🇸United States @camhoward

Hi @leslieg -- Thanks, I understand. It seems I misunderstood the question from @ivnish and thought he might have been opening a discussion about the logo itself. Since that was not the case, the maintainers should proceed with whatever they think best.

@ivnish -- OK, thanks for the clarification.

I see now your question needs to be addressed by the maintainers and was not a question for general discussion about the logo itself.

RE: Question from @ivnish "Is there any problem with this?" -- Are you asking from a technical perspective or a visual perspective?

If the latter, it's not clear to me why a dump truck is being used to represent Backup and Migrate.

I get the idea of using a truck to move something from one place to another (migrate), but why a dump truck? IMHO, a dump truck implies carting away debris more than it does moving to a new location.

Why not use a moving truck or a flatbed truck or something that conveys a more positive image of moving to a new home? Or, an image of a safe or storage locker to convey the idea of backing up a site for safekeeping?

Most of the proposed module logos have been so creative and represent the modules very well. I found this one a bit jarring.

I hope this helps.

This has certainly been a challenge with conflicting sets of directions.

Google's directions in step 2 of their "Get started with Tag Manager" help center are to "Install a web container." That page says "...select your container ID (which starts with 'GTM')." They provide example code that includes a GTM-xxxxxxxx ID.

That page also contains a link for "Learn how to install the Google tag with a website builder or CMS" which, in turn, has a link for how to install on Drupal and directs people to use Google Analytics.

However, the Google Analytics module on drupal.org is listed as obsolete and deprecated. It recommends using Google Tag.

The Google Tag module requires "Google Tag ID(s) in the form of UA-xxxxx-yy, G-xxxxxxxx, AW-xxxxxxxxx, or DC-xxxxxxxx" which don't match the Google directions to install the Google Tag Manager container ID, which starts with GTM.

The instructions from @mglaman in #3319523-8: Is Google Tag Manager using a new format for the container ID "g-xxxxx" instead of "GTM-xxxxx"? → say "If you're using Google Tag Manager, configure Google Analytics (G-XXX) in Google Tag Manager's UI."

Here's what I did:

1. In Google Analytics, set up an account and GA4 property for the site. Added a web data stream with the specific URL of the site. That resulted in a Measurement ID tag in the form of G-xxxxxxxx.
2. In Google Tag Manager, created a new tag of type Google Analytics, and copied the Measurement ID tag from Google Analytics into the Google Tag in Google Tag Manager.
3. In Drupal, on the Google Tag module "Default Tag Settings" page, pasted the G-xxxxxxxx Measurement ID tag from the Google Analytics GA4 property web data stream.
4. The Drupal site is now sending data to Google Analytics.

It works for tracking site visits, but seems to defeat the purpose of using Google Tag Manager (GTM).

As I understand it, the goal of GTM is that one GTM tag is installed on a website and then all tags for measuring site visits, ad conversions, etc. are set up and managed in GTM.

The way Drupal's Google Tag module is working, it appears that as new tags are created in Google, they also have to be added in Drupal as additional tags, which bypasses using Google Tag Manager as a central place for managing tags.

If Drupal's Google Tag module accepted a GTM tag, social media managers and ad managers could create new tags in Google Tag Manager without needing to send them to the website manager for installation in Drupal.

I hope this is helpful in both confirming why the process is so confusing and providing one way to set it up.

If I have missed a step or a way to install the Google Tag Manager GTM-xxxxxxxx ID in Drupal, I would love to learn more!

Thanks, this looks helpful!

A couple questions for clarification:

Many of these hosting providers offer multiple types of hosting, such as dedicated hosting, cloud hosting, VPS hosting, and shared hosting. Is the plan to test all types of hosting or are there minimum requirements?

Are you looking for people to start testing now or wait for further instructions/developments?

@tokosefi -- I'm sorry to hear that my last post didn't help. I don't have any additional advice. None of my sites are using Drupal 10 with Adaptive Theme.

Blocks are theme dependent. If you change your theme, or create a new subtheme and make it your new default theme, you have to place the blocks in the correct region for the new theme.

Go to Structure > Block layout and place the blocks where you want them. For example, place "Main navigation" in the "Navbar" region.

I was having the same issue on all my D9 sites using at_tool 2.0.5.

I am finding that reinstalling at_tool 2.0.5 is resolving the error messages. Running cron and clearing caches before reinstalling didn't resolve the error messages for me. So far, reinstalling is working.

I'm not sure why. The ^^10 error was not in at_tool 2.0.5, only in at_tool 3.0.0.

Many thanks to @roblog for reporting the issue, to @dineshkumarbollu for creating a patch, and to @mattbloomfield for fixing the issue.

@gnikolovski -- Thanks for the quick response, explanation, and fix.

Yes, hierarchical_taxonomy_menu 2.0.x-dev, as updated on April 1, 2024, resolves the issue. The Hierarchical Taxonomy Menu now works the same way using the settings in my original post when added via Layout Builder and via Block layout.

Thanks very much!

For anyone else trying to figure this out:

Go to Structure > Content type and select the content type that includes an entity reference to the taxonomy.

On the "Manage fields" page, edit the entity reference field. In the "Reference type" section, change the "Reference method" from "Default" to "Taxonomy term selection (with groups)." Change the "List item prefix" if needed and save the new settings.

camhoward → created an issue.

@MegaphoneJon -- I'm happy to hear that! Thanks for letting me know.

@tokosefi -- Yes, temporarily switching to a different theme while making these changes is recommended. Your site should be in maintenance mode while you do this, so the change will not be too visible to the public. As soon as you make the changes and check the site, you can switch back to your custom theme and take the site out of maintenance mode.

@tokosefi -- I understand the frustration of not knowing how to do something, but please don't accuse people of giving up or being "unfair" when they are volunteering their time to provide a resource for you for free. You could also do some of your own research through the issue queue to find the directions about how to switch from Adaptive Theme 2.0 to the original AdaptiveTheme.

Matt Bloomfield generously created a fork of AdaptiveTheme when the original creator and maintainer was no longer available.

When Matt was granted security coverage and the maintainer role for the original AdaptiveTheme, he switched to maintaining and updating the original. He announced that back in 2021.

I updated all my Drupal 9 sites to use the original AdaptiveTheme with AT Tool 2.0 at that time.

Switching from Adaptive Theme 2.0 to AdaptiveTheme was very easy. Here are the steps I followed:

1. Download the latest version of AdaptiveTheme from https://www.drupal.org/project/adaptivetheme → .
2. Backup your site.
3. Put your site in maintenance mode.
4. Set Bartik or Olivero as the default theme.
5. Delete at_theme from the themes directory.
6. Upload adaptivetheme-8.x-5.2.tar.gz to the themes directory.
7. Extract the tar.gz file which creates the adaptivetheme directory.
8. Clear Drupal's caches.
9. Set your previously created custom theme as the default theme.
10. Check that everything looks/works as expected.
11. Delete adaptivetheme-8.x-5.2.tar.gz from the themes directory since it's no longer needed after the adaptivetheme directory is created.
12. Take the site out of maintenance mode.
13. Clear Drupal's caches.

People using composer and/or drush may need to do things a bit differently.

This is not the same as using a symlink, but is another option.

I'm having the same issue with all-day events starting early with Calendar View 2.1.7 on a Drupal 9.5.11 site, so it's not limited to Drupal 10+.

When the timezone is set to America/New York, all day events display as starting at 7 p.m. the day before (UTC -5). Even if I set specific times for an event, such as as starting at 12:01 a.m. and ending at 11:59 p.m. on the day of the event, instead of using the "All Day" option in Smart Date, the calendar displays the date as starting at 7 p.m. the day before and ending at 6:59 p.m. the day of the event.

The time shift also happens when using the Drupal core Date field instead of a Smart Date field.

And, as @michaelschutz found, if I change the "Time zone override" for the date field in the View to UTC, all-day events display correctly on the calendar.