At this point, we don't need a Drupal 8 module. As Drupal 11 has just been released, and Drupal 9 is nearing EOL, I would say work on an update that will be compatible with Drupal 10/11, and then keep it up going forward.
@anybody,
Did you notice this is NOT a "duplicate"? I stated clearly in my message that I saw the thread about updating to Drupal 8, and I see that at about the same time you closed this message as a duplicate, you replied there. This thread was created, rather than responding to the thread you state this to be a duplicate of, as that thread was created in 2017, and the last response from more than 4 years ago had gone without response. Not to mention that the original thread was about Drupal 8, and we are now needing a Drupal 10/11 compatible version. If you are stepping in as a maintainer, and intending to make this update, that's great. Checking, I don't see you listed as a maintainer, but I look forward to this much-needed, long-awaited update.
We really need an updated version of this. It would be a great addition to Drupal 10.
Yes, you're right. I was concerned as #3 and #4 both came back with what appeared to be errors, but #5 worked fine, and completing the whole process the themes were uninstalled, and the update routine ran without issue.
Thank you, very much. I appreciate your help and your patience.
Thank you. No joy.
composer require 'drupal/material_base:^3.0'
./composer.json has been updated
Running composer update drupal/material_base
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
- Locking drupal/material_base (3.0.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
- Installing drupal/material_base (3.0.0): Extracting archive
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
57 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Cleaning installed packages.
No security vulnerability advisories found.Then
drush cr
[success] Cache rebuild complete.So far, so good. Moving on...
drush thun material_base_mdc
In ThemeInstaller.php line 263:
Unknown theme: material_base_mdc. I also tried #4, just to see what happened. Same result. I saw no point in attempting to continue.
I uninstalled Bootstrap Paragraphs.
Apparently not. I note that your (@kerrymick) response was about a month ago, and the project shows a version 5.0.1 available, that was released 11 April 2024. I updated to that version, and attempted to run my database updates. I tried both via drush (drush updb) and via the browser, (/update.php).
Drush responds with: (See Screen Shot 2024-04-24 at 2.43.16 )
and UPDATE.PHP responds with (see Screen Shot 2024-04-24 at 2.14.36)
Same messages as before.
I've noticed this issue too. Following, awaiting patch.
@jonathanshaw
With all due respect, how can you say it "works as designed" when the documentation mentions a twig file to update, and that file outright does not exist? I went into the https://git.drupalcode.org/project/simplenews repo, and I've gone through every version of this module from the earliest versions of the Drupal 8 update, forward, and the file simplenews-block.html.twig simply does not exist, yet for some reason through at least a half-dozen updates, this TWIG file continues to be referenced in the documentation. And even the "fixes" that some have suggested in this thread, others are saying don't work. And this is an issue that has been open in various threads since at least 2016. This isn't an issue of needing to update the documentation. The docs are referencing what is needed, to do what (based on the numerous issues and responses on this subject we've seen) a large number of us want to do. Can someone kindly explain to me why it is so difficult to write this single TWIG file? I'd do it myself, if I had any idea what it needed in the way of content. But it would seem like that should be a 10-minute project for any of the maintainers.
Why this module hasn't been ported to D8/9, is probably because there hasn't been enough need for it.
I think this is very much a double-edged sword. I've lost track of how many times I've discovered a module that seems to be just what I need, except that it is a version or more behind. Opening issues asking the maintainers about the status of the update often go completely ignored. When something comes out in "Late D7", and many don't even know it is there until "Early D8", or even "D9", and people are asking about the updates, and getting no response, this isn't a good thing.
I'm not sure if the patch didn't get pushed through or what, I started a fresh D10 install, installed admin_toolbar and diner_delights, and activated the toolbar and this theme. And as of 31 October, 2023, the admin toolbar is still being overlayed by the theme, so the toolbar is not accessible. (see screenshot).
I have just encountered this issue as well. In my instance, it was a Drupal 9.5.11 installation; but same situation. Everything was working fine, I installed the theme, and set it as default, and the Admin Toolbar was no longer accessible. I couldn't click ANYTHING on it. I could click the buttons/etc. on the site itself, but nothing on the Admin Toolbar. I manually entered /admin/appearance in the URL area of the browser, and changed the theme to another, and immediately the Admin Toolbar worked correctly.
@dalemoore Thanks for that! I had figured, based on what the message said, that it was something like this, but I appreciated being able to find specifically what "modules" to change to/from. Much appreciated!
Thanks.
Never mind. I found it. I appreciate the help.
@shiv_yadav,
Thank you for your help. I did further work, and found the issue was apparently relating to the placement of a "Content Wrapper" field. The box I refer to is within the white space, below the bottom of the photo.
Taking this as a "Learning Opportunity"...
If I may (as a somewhat "intermediate" Drupal Developer, with a lot still to learn) ask what may be a dumb question, as these forums in Drupal.ORG seem to use a somewhat abbreviated date format on posts, (i.e. "about 2 hours ago..." or "2 months ago" "5 months ago" or "10 years ago"... as opposed to "Wednesday, March 15, 2017, @ 9:48 am UTC" or the like), I've looked through other issues and seen conversations similar to this, where a patch is created, Merge Request is issued, but with only loose times on the messages (especially as you get beyond 24 hours), How can I tell whether or not the patch(es) have already been merged into the current version of the theme/module, or if I would still need to apply them?
Thank you!
As an update, it appears that CKEditor 5 doesn't like an "empty" span tag, as @KarinG has in her example.
When I change the code to
<style>
.legend-dot {
font-size:3rem;
text-align: middle;
}
</style>
<p><span class="legend-dot" style="color:#b51616">•</span> Slalom <span class="legend-dot" style="color: #cc9900">•</span> Freestyle
Drupal retains the <span> tags. But when I use the <span></span> tag, Drupal/CKEditor strips the span out every time.
I notice that for some reason the error message ends up being partially "redacted" if you will... as I highlight the message, I'm able to see the full message.
I agree. I find this same issue. And as soon as I change to another theme the issue goes away. Seems to be specific to this theme.
Here's what I get with harmony_haven (see example 1)
And here is what I get with any other theme. (see example 2)
I've installed a local "Testing Sandbox" project using DDEV, and as always, installed Admin Toolbar. I'm not seeing the "flash" that I had been, but I do notice that Admin Toolbar can be "changed" based on the active theme. I used a theme that I wanted to check out, and I found this chunky, ugly mess (See Example 1). I checked the other project that prompted me to open this issue initially, and it now seems to be working well. I didn't notice it, but I presume that an update added the patched information above. I came back to the sandbox project, and changed to another theme, and it seems to work fine (See Example 2). I switch to the "Olivero" theme, and likewise, the toolbar works fine. I'll be making the maintainers of the problematic theme aware of this, but thought I'd share it here as well. As I presume that the new issue I'm seeing relates to the one theme, I'm happy. One of my "go-to" modules seems to be working well again.
OK. Let me work on it. I've been milling around some ideas.
You will love Composer! I too started out with Drupal 7, so I remember the "old way" of doing things. Composer makes life 1000x easier.
I'm not one to "reinvent the wheel" as the saying goes. If token will do the job, I'm open to it. I think I alreadyhaveit installed in my project. I'll see if I can figure out how to make it work for my idea.
OK. I've found a part of the problem... not sure of the cause...
The fingers were working faster than the brain; I'd been modifying and repasting updated code, overwriting what was there/not working, so I wasn't looking at what was there... but when I did stop to look, I find that the reason the colors aren't showing up on mine is, for some reason, Drupal is stripping out a lot of the code. I paste in @KarinG's sample,
<p><span class="fc-event-dot" style="background-color:#99cc33"></span> Slalom <span class="fc-event-dot" style="background-color:#c58917"></span> Freestyle <span class="fc-event-dot" style="background-color:#f24fe7"></span> Leader/Instructor/Coach Development <span class="fc-event-dot" style="background-color:#800080"></span> Multi-Discipline <span class="fc-event-dot" style="background-color:#555555"></span> Other <span class="fc-event-dot" style="background-color:#ff6600"></span> Festivals <span class="fc-event-dot" style="background-color:#3366ff"></span> Paddler Development <span class="fc-event-dot" style="background-color:#c11b17"></span> Club Events <span class="fc-event-dot" style="background-color:#066066"></span> Canoe Polo </p>
and save it, and when I come back and look at the source that was saved, what is there is:
<p>
Slalom Freestyle Leader/Instructor/Coach Development Multi-Discipline Other Festivals Paddler Development Club Events Canoe Polo
</p>Drupal is stripping out all of the necessary information. I have this set as FULL HTML format in the editor, so I'm not sure why it is stripping out all of the information. So I've found the CAUSE, now I just need to figure out the solution.
OK... I'm confused. I'm not arguing that it is "working as designed", but if, as you say, the module doesn't support the pager feature, why does the example setup given right here in https://www.drupal.org/project/fullcalendar_view → specifically call out using it? (I refer to point '5' in the attached screenshot)
In this case, that pager setting is cumulative. Once I enter the 13th event, one of them no longer shows up. It doesn't matter how much are on any given month/page.
I have tried both @KarinG's method and @bcobin's, and wasn't able to get either to work. The text shows up in each case, but the colors don't appear in either one. I thought that the issue with @KarinG's segment might have been the missing fc-event-dot section in CSS, but @bcobin's includes the complete CSS, and yet I get the same result in both instances. (see attachments)
You're right, I was. Many thanks. Seems to work right now.
I must be doing something wrong somewhere. Under the "Manage Display" screen, I've tried setting the field in question to both "Hidden" and "Visually Hidden" and in both instances, it still shows up when I go to create new content of that type. I've also noticed that, while the Label for this is hidden, the actual value of that field shows on the resulting node.
With the second content type, it would basically never need to be changed. The only reason that I'm even using it (the entity reference) is that the view needs it to work correctly. So hard coding it somehow seemed like it would be the way to go. I've been working with Drupal since somewhere in the D7 days, so I consider myself an "intermediate" developer. I don't know everything, by any means, but I'm not a "beginner".
I'm presuming that when the full Taxonomy list is used (as in that first Content Type), that the term that the
My thinking, as I asked this, was that possibly I could put a bit of Javascript or PHP code somewhere, which would basically just say:
const term = foobar; With "term" being whatever variable name that Drupal is using for this... though I'm not sure where I'd need to place it, or even if this is a workable option.
Thank you. Somehow I overlooked that one.
NO! NOT Fixed. I saw these responses, I went back, ran composer update and checked, and the same issue still exists. And I've found other issues as well, all display related.
a) I've checked, to make sure, I am running the same version available from the profile here. the same issue shows up when I activate the theme and view it.
b) When I view the site, using this theme on my phone, the Navigation does not show up at all. No "hamburger menu", nothing. Just the Logo and the black box. So on mobile, no way of moving about the site. It does show on Desktop.
c) I have placed the Footer Menu and another block of information in the Footer area, but it doesn't show up at all. On any version (Desktop or Mobile), nor on any page. I get the Copyright notice at the bottom, and the Social Media block, but nothing else. When I view the layout example, the Footer isn't showing up anywhere, and oddly the two "sidebar" regions show one above the other at the bottom. So it appears that the Footer area is missing. It comes up in the STRUCTURE>BLOCK LAYOUT area, but apparently got left out of the TWIG file.
Just to give my unasked for $.02, My thought is that the best way to accomplish this would be with a Modal. Targeting the scripture output to a separate screen/tab would seem to be less than ideal, as the user has to first, be aware that this new tab has opened (which, granted, should be fairly obvious, but, as we know, not always.) Then they've got to switch from the active Drupal tab to this other tab, read the reference, then find the original tab (which can sometimes be tricky if you're one of us who may have multiple tabs open) to switch back to the Drupal tab. If a Modal were used, the user could click the link, the reference pops up on the same screen, they're able to read it, and more easily reference the original context, and then simply close the modal when they're done, to return to the original content.
As I said, I understand that these people are volunteering their time. My only "complaint" (and I use the term lightly) is, as you touch on, there are a few tools available there. And when a project has 3... 4... sometimes a half-dozen or more maintainers listed, and the project is listed as being actively developed, and yet you ask a question/reach out for help, and a month later, nothing. And you look and notice that other issues are likewise...or even more so, you look and notice that some issues seem to be ignored, while others are responded to in a day or so... it makes you start to wonder if there is some "rule" or procedure that you're unknowingly violating.
OK, fair enough. The thread I quoted as an example wasn't mine, just an instance of the type of situation I was referring to. As I say, I'm not calling anyone out, nor complaining; but in looking, I don't see anything on his profile, or anywhere that indicates that he is a moderator. IMO it would be helpful if these people were identified somehow, to avoid this sort of confusion.
Here is an example of what I'm referring to in point "b"
https://www.drupal.org/project/bible/issues/3276758 💬 Offering to co-maintain Bible Closed: outdated
I'm not saying anyone did anything wrong, but I'm unclear why "apaderno" is taking the actions he is, when he doesn't appear to be a maintainer, or at all involved with the project in question.
@flabel, I don't think that this is the same thing as what you're referring to. Looking at the examples shown in the ~/drupal/issues/2998451, it shows a brief (as the title describes) flicker, what we're talking about here is a full 1 to 2 second flash of the content of the Admin Toolbar. And, as I say above, if I uninstall the Admin Toolbar module it goes away. While the example showing in the issue you quote doesn't appear to be using the Admin Toolbar module.
I understand that. As I say, I believe this dependency was changed, or added back in by some module or something I installed; this warning wasn't showing until recently. I am already running Composer 2 (version 2.4.4, to be specific). Is there some way of finding out where this came from? The project is a Drupal 10 project, installed as Drupal 10, using Composer 2. So I don't know of any reason why the older template should be the one being used. If it is indeed just the old profile somehow, that's good, I just want to make sure before I go changing to composer/installers, and causing issues with the site.
I'm not sure what the issue was. I completely uninstalled the module, removed the view, removed all of the content items related to it, took everything completely back to square one, flushed caches, reinstalled the module, recreated the content nodes, rebuilt the view... I'm not sure what was done differently this time, but the colors are now working.
Now to try to get Recurring events to work.
Yes, 10.1.0
As I understand how frustrating it can be, to ask a question/ask for help, and be completely ignored, I'll let you know that this isn't the module causing your problem. You want
https://www.drupal.org/project/fullcalendar_view →
Hope this helps.
I tried patch #2 on my DDEV local Drupal 10 install, I still get the same error message. As soon as I change to another theme it is fine. I get it with both "Coffee" and "City" Zymphonies themes.
OK, it worked. Took a cache clearing and a couple browser refreshes.
OK, I've added this code to my CSS, but once this is done, do I need to modify the settings in /admin/config/services/youtubechannel to get it to work? It isn't appearing to be responsive, just adding the CSS. Am I missing something?
I'll check it out and let you know.
The OpenChurch theme works, however, I see that same "broken block" message at the top where the hero sections should be. (see attached screenshot). Looking at the example screenshot you provide for the theme ( https://www.drupal.org/files/project-images/screencapture-openchurch10-d... → ) as you can make out in my screenshot, the default Open Church logo shows up, as well as the nav bar (though it's a white text on white background, until I mouseover something). The three sections throwing the errors, I presume match up with the top three sections. The "Latest Articles" section shows up, the "Homepage Bible Verse" section is throwing that same error, and likewise with the Gallery section. (for the record, I haven't populated the Bible verse, nor the gallery section). The Newsletter subscription and footer sections are displaying fine.
@drupalninja99 - Hi Jay,
I followed the instructions in drupal.org/project/openchurch, which says to install the core module first and then the theme. I did not use the instructions in the link you share, as I work through composer, so while it was installed 3 months or so ago, I'm pretty sure I would have used a basic composer require drupal/openchurch_core command. I just ran a composer update as I am writing this, and I notice that it updated core to 3.0.0 alpha 3 and theme to 3.0.0 alpha 5. After the update, I checked and still see the same error messages. As I say, I have attempted removing and reinstalling the theme, but that doesn't seem to make a difference. Should I try removing and reinstalling core? I presume that I would have to remove the theme first, and then remove core, and then reinstall core and then theme? Figure I'll ask about that, before I get too far ahead of things.
I'm seeing this on everything in the Hero section, and everything in the Content Above section.
Looking at this same screen using various themes, it is strange, because it is not happening on EVERY theme... for example, Oliverio does just fine. However there are some that end up as a mix, some of the titles being black while others are still white. I've screenshot a few examples. I'm also noticing the absence of the "exit" button/tab to get out of this screen.
That link just gives me an error message when I click it.
To "bottom line " it, it isn't working
As designed, or something isn't being explained clearly, as I have followed the steps to implement colors, yet all of the events, regardless of the taxonomy, are showing up as the same color.
While we're working on rolling this into things, it would really be nice if there were the option to include Sunrise/Sunset times for selected days. (i.e. "Display Sunrise times every Tuesday" or "Show Sunrise and Sunset times on the 4th Thursday of each month" or whatever.)
I am attaching a screenshot of my Views settings (the "11.08.40 AM" image). I questioned if the "Content: Content type (= Event)" setting in "Filter Criteria" might be the cause, but I'm not sure how else to set that, as what I want showing up on the calendar are items that are "Event" content type. I also questioned whether the "Content: Tags" selection in the "Fields" section might be the cause, but I don't believe that is the issue, seeing as (see "11.15.33 AM" screenshot) the "Event Taxonomy Field" is "Content: Tags", which then allows me to select the "calendar_tags" vocabulary.
I'm not saying it doesn't "work as designed". But what you are showing there is showing me how I can make the various content types show on the calendar in different colors. That's all well and good, though if I'm being honest, I'm not sure why I would want to, for example, put a Blog post on my calendar, but regardless, is it not logical that I am more likely going to want to have a "Category" for each "Event" that I am creating (for example, "Meeting", "Webinar", etc.) where I can make all of my meetings one color, all of my scheduled webinars another, etc. )
Digging deeper on my own, I was able to find that when I change the "Event Taxonomy Field" from "None" to "content:tags", and create a separate taxonomy type called "Calendar Tags", and place "Meeting", "Webinar" and such in there, I am then given the ability to select colors for each "category" of things that may be on the calendar.
Information is outdated to D7, maybe D8 references.
BEGRAFX → made their first commit to this issue’s fork.
I've talked with the css_editor folks, there was an issue there, but I worked up a patch, and CSS Editor is now working fine with Drupal 10. I thought that would resolve the issue, but I'm still getting this same error message. I'm not sure WHY I'm getting the part about CSS Editor, seeing as it is already installed, active, and working. I can only presume that Composer doesn't "like" my patched version, and I'll need to wait for them to push an update.
Even using the '3.0.3' method that @GreenReaper shares, I still get:
Your requirements could not be resolved to an installable set of packages.
Problem 1
- drupal/css_editor 2.0.1 requires drupal/core ^8 || ^9 -> found drupal/core[8.0.0, ..., 8.9.20, 9.0.0, ..., 9.5.3] but the package is fixed to 10.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- drupal/aristotle 3.0.3 requires drupal/css_editor ^2.0 -> satisfiable by drupal/css_editor[2.0.1].
- Root composer.json requires drupal/aristotle ^3.0.3 -> satisfiable by drupal/aristotle[3.0.3].
Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
My patch should resolve the first portion of this issue. I'm guessing the lock file isn't happy, so, like I said above, I'll have to wait for them to push an update of CSS Editor. I'm presuming that once that happens, that will "fix" the first part, and fixing the first part will resolve the second part. I'm not sure what the 3rd part -Root composer.json requires... is about. I don't see an issue here. Not sure why it is even mentioned.
OK! I've made the change, tried it out in my local test site. Seems to work. No problems noted so far. Here is the patch.
Nope. Doesn't seem to make any difference changing DOMPurify to dompurify. I've reloaded, I've cleared the caches, doesn't seem to make a difference. Same warning.
Sorry about that. Didn't mean to duplicate. Not sure how I missed my earlier post on this, when I searched.
Let me work on that!
I'm getting the same message. I've installed the library, but still get the message.
Something I notice, the profile page says in part:
Please download the library from the above location and put it in libraries folder. After that unzip and rename the folder to 'fontawesome-iconpicker' (i.e. remove the version suffix). After you do it, the fontawesome-iconpicker.js file should be available at /sites/all/libraries/fontawesome-iconpicker/dist/js/fontawesome-iconpicker.js.
I'm presuming that this is a D7 reference (and should probably be updated, or appropriately notated); and that root/libraries/fontawesome-iconpicker/dist/js/fontawesome-iconpicker.js is the correct path for a Drupal 10 install.
Here's the Composer message:
- drupal/css_editor[2.0.1, ..., 2.0.x-dev] require drupal/core ^8 || ^9 -> found drupal/core[8.0.0-beta6, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.0.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
I'd have to double check which version it is that a theme I was using was pulling, but while the Theme claimed to be Drupal 10 compatible when I went to install it, I got a Composer error, that CSS_Editor wouldn't work.
A Drupal 9/10 compatible release is needed, for a number of other modules that have this one as a dependency. Willing to do what I can to help with this project.