I can no longer reproduce the bug. I suspect the bug was occurring because I was misusing a views template. The drupal_field() function is working fine in other contexts.
arnoldbird → created an issue.
After a move to Azure, when I visit /admin/reports/status, I see this error:
Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Invalid object name 'sys.master_files'.: SELECT DB_NAME(db.database_id) DatabaseName, (CAST(mfrows.RowSize AS FLOAT)*8)/1024 RowSizeMB, (CAST(mflog.LogSize AS FLOAT)*8)/1024 LogSizeMB, (CAST(mfstream.StreamSize AS FLOAT)*8)/1024 StreamSizeMB, (CAST(mftext.TextIndexSize AS FLOAT)*8)/1024 TextIndexSizeMB FROM sys.databases db LEFT JOIN (SELECT database_id, SUM(size) RowSize FROM sys.master_files WHERE type = 0 GROUP BY database_id, type) mfrows ON mfrows.database_id = db.database_id LEFT JOIN (SELECT database_id, SUM(size) LogSize FROM sys.master_files WHERE type = 1 GROUP BY database_id, type) mflog ON mflog.database_id = db.database_id LEFT JOIN (SELECT database_id, SUM(size) StreamSize FROM sys.master_files WHERE type = 2 GROUP BY database_id, type) mfstream ON mfstream.database_id = db.database_id LEFT JOIN (SELECT database_id, SUM(size) TextIndexSize FROM sys.master_files WHERE type = 4 GROUP BY database_id, type) mftext ON mftext.database_id = db.database_id WHERE DB_NAME(db.database_id) = :database; Array ( [:database] => cop-eed-test ) in sqlsrv_requirements() (line 65 of modules\contrib\sqlsrv\sqlsrv.install).
My Drupal version is 10.2.2.
I had a similar issue today. Even after re-installing calendar_view, I continued to see an error saying the calendar_month plugin did not exist. Clearing the cache did not fix the problem but visiting /update.php fixed that issue. I was then able to delete the view display that depends on the calendar_view module.
However, I was still not able to delete the calendar_view module without deleting my events view, even though none of the displays in the view actually depended on the calendar_view module at this point. I then exported the config for the view and saw that calendar_view was still listed as a dependency in the config, even though none of the view's remaining displays use any of the formats provided by calendar_view. I then manually removed the dependency on calendar_view by editing the view's config file, and I then imported that config. I was then able to uninstall calendar_view without deleting my events view.
arnoldbird → created an issue.
The README in #15 does not explain how to use the module. It says,
3. Inside the View editor, find the section that lists the exposed filters.
Why "find the section"? Why not refer to the specific part of the GUI that you have in mind? Is it the "Exposed Form" section? Is it the "Filter Criteria" section? Which is it?
4. After adding the Views Date Filter, configure its settings based on your requirements
After adding the Views Date Filter? You skipped telling us *how* to add the Views Date Filter. I can't figure it out. After enabling the module, I don't see any reference to a "Views Date Filter" anywhere in the view settings.
My issue was caused by this core bug: https://www.drupal.org/project/drupal/issues/2927004 🐛 Media image edit isn't saving changed image and remove the existing image Active
In my case, this was the solution: https://www.drupal.org/project/drupal/issues/2927004#comment-13480409 🐛 Media image edit isn't saving changed image and remove the existing image Active
I have found a separate bug in my site that might explain the strange behavior I'm seeing with this module.
Without this module installed, if I create a media item and then subsequently visit the form for that entity, the file widget is sometimes empty.
Still, it would be helpful if someone could confirm that the behavior I've described for "Overwrite original file" is not the intended behavior.
arnoldbird → created an issue.
After uninstalling and re-installing the module, I continue to see the password filled in. See attached screenshot. However, I suspect this might just be something my browser is doing.
arnoldbird → created an issue.
Same question. How do I clear the password?
If I empty the field, the module continues to use the stored password.
Looks like I haven't done any work on the module since 2019. Doesn't get much more stable than that! Actually I've had no use case for the module, myself, but if someone else wants to contribute, let me know how I can facilitate.
arnoldbird → created an issue.
In my site, this bug is fixed by the combination of #4 and #6 at https://www.drupal.org/project/infogram/issues/3420926 🐛 Errors when name is not set in code Needs review
I think we just need to change this...
$twig->loadTemplate($this->templatePath);
...to this...
$twig->load($this->templatePath);
In Drupal 10.1.6, after I apply the patch, I get...
The website encountered an unexpected error. Please try again later.
ArgumentCountError: Too few arguments to function Twig\Environment::loadTemplate(), 1 passed in /var/www/html/web/modules/contrib/infogram/src/Infogram.php on line 32 and at least 2 expected in Twig\Environment->loadTemplate() (line 330 of /var/www/html/vendor/twig/twig/src/Environment.php).
arnoldbird → created an issue.
arnoldbird → created an issue.
I think I found a way. If I override the input--file.html.twig template in my sub-theme, and change the usa-file-input class that appears in that template, the input is no longer styled like the USWDS component, but still works as usual.
arnoldbird → created an issue.
arnoldbird → created an issue.
arnoldbird → created an issue.
I got my answer here: https://www.drupal.org/project/webform/issues/3283625#comment-14543894 →
I think I'm getting warmer. The YAML errors appear when only one element has been added to the Custom Composite element. And the same errors can appear when more than one element is added, but one of them is a select element and the "Custom options" aren't filled in properly. But I'm not sure how to use this part of the interface. See attached screenshot.
arnoldbird → created an issue.
The problem is more general than some commenters suggest. For example, if you place a block inside a mega menu, there is no way to access the contextual links for the block. Even if you do click the Edit link in the upper right of the header this only reveals the locations of the contextual links -- it doesn't open them. As a result, as soon as you click on the pencil icon inside a mega menu, then menu section (in many sites) will close before there is any opportunity to access the links. The developer either has to hunt for some way to open the contextual link with custom code, or add a separate edit link to the block template with custom code.
Separately, the text for the Edit button should be something like "Show contextual link locations," to be accurate. Or, in a perfect world, it should read "Show contextual links" and should not only reveal the pencil icons, but also reveal the links themselves.
arnoldbird → created an issue.
arnoldbird → created an issue.
In the new webform/migrations dir, copy either the d6/* or d7/* files up a level, i.e. webform/migrations/d7_webform.yml;
I don't know what files you mean by "the d6/* or d7/* files." What d6 or d7 files do you mean?
There is no "webform/migrations" directory. Do we need to create that directory? Do we need to copy the migrations directory from the webform_migrate module directory to the webform directory?
After reading the instructions in the latest patch, I still don't know how to use the module. It seems like one or two steps are missing.
Thank you.
Copy the "migration_templates" and "src" folders from the webform_migrate directory to your existing webform directory;
Please don't say "existing webform directory." That could mean either the destination site or the old site. Both exist.
Please say explicitly whether you mean the old site or the new/destination site.
In step 3, I didn't realize that there is an entity reference display option, and that is what the instruction mean by "Create a new entity reference view". So I never really performed step 3. Still, it doesn't seem like it should be possible through any combination of actions to produce an error that blocks the user from editing a field's settings.
I was able to recover the site by changing the field settings programmatically:
$field_definitions = \Drupal::service('entity_field.manager')->getFieldDefinitions('node', 'my_content_type');
if (isset($field_definitions['field_my_field'])) {
$current_settings = $field_definitions['field_my_field']->get('settings');
$current_settings['handler'] = 'default:node';
$field_definitions['field_my_field']->save();
}arnoldbird → created an issue.
This deletes the setting:
drush config-delete filter.format.pm_description
Now I can install PM.
arnoldbird → created an issue.
Naming collision with https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
That was the problem.
The problem is caused by the existence of a _media_create() function in a custom module. I don't know why that would be, but perhaps that function name conflicts with something else in Drupal. If I change the function name to _media_create2(), the problem goes away.
I tried creating a new temp directory and changing my settings file accordingly. All is well according to the status report page, but I still get the same memory errors when I visit any of the pages for adding media bundles. For example, /media/add/audio.
Based on the code in FileSystem.php, it looks like Drupal can't write to the temp directory. However, there is no indication on the status page or the file file system config page that there is any problem with my temp directory, and I am able to create media entities via the UI with no problem.
arnoldbird → created an issue.
For me, it appears this has solved the problem: https://www.drupal.org/node/2481341 → -- Download the latest cacert.pem.
Though the page mentions reCAPTCHA, it describes a solution that likely applies to a lot of themes and modules.
Actually, the solution at the above URL appears to have solved multiple problems with my Drupal 10 sandbox site.
"follow the instructions there"
There are no instructions there. I also had a look at the README, and there are no instructions there either.
arnoldbird → created an issue.
arnoldbird → created an issue.
arnoldbird → created an issue.
arnoldbird → created an issue.
This was a theming issue. I am closing it.
arnoldbird → created an issue.
arnoldbird → created an issue.
It's not clear if Drupal 10 is a good option at this time. The sqlsrv project page says: "Initial D10 support currently under testing and development. Please use 4.3.x for production." https://www.drupal.org/project/sqlsrv →
Version 4.3.x does not support Drupal 10.
arnoldbird → created an issue.
"undoubtably the same platform problem"
I could definitely believe these are related issues, but we haven't verified this. Many times, when encountering two issues at roughly the same time, I have mistakenly concluded that they were related, only to find later that they were not related. The platform is unchanged from when I was running Drupal 9, and didn't experience these issues in Drupal 9, for what it's worth.
Logically, I can't think of why a bad system path in a view could result in a thumbnail (in a different column) temporarily not displaying. There is nothing wrong with the image src in the Thumbnail column at admin/content/media. I would tend to expect that if the two issues are related, the thumbnail would not appear after I press CTRL+Shift+R.
Thanks
I added some information about my environment to the end of the issue summary just now.
Nothing is showing up in the browser console. There are no errors. I also had a look at the Network tab of the Web Development Tools. I don't see anything notable there at any point during the file upload, nor when I save the form.
"I suspect the platform may be very slow to generate thumbnails."
No matter how long I wait, the thumbnail doesn't appear. I have verified the thumbnail file itself does appear in the file system immediately, in the correct location. That is, it appears immediately in sites/[my-site]/files/styles/thumbnail/public/[YYYY-MM]. However, the preview isn't displayed at /admin/content/media until I press CTRL+Shift+R.
Please see the attached screenshots.
media-name-link-broken.png shows the most recent upload at admin/content/media. The "test image" link in the Media Name column should link to /media/42/edit, but instead it links to /media/42. And when you click on that bad link, you see the error in media-image-bad-url.png.
In other words, the issue is not that the media doesn't load at the bad URL -- we wouldn't expect it to load at the wrong URL. Rather, the issue is that the Media Name column has the wrong link href. Drupal is somehow supplying the wrong URL for the links in the Media Name column at /admin/content/media.
What kind of information would help? I have attached a screenshot showing what I see at /admin/content/media after uploading an image.
Thank you.
arnoldbird → created an issue.
I can't reproduce it at https://simplytest.me/
It must be something specific to my environment.
arnoldbird → created an issue.
You use it with drush. Have a look at the README file.
arnoldbird → created an issue.
arnoldbird → created an issue.
arnoldbird → created an issue. See original summary → .
The module is not documented at all. How do we use this module? A few sentences in the README, or on the project page, could make all the difference.
arnoldbird → created an issue.
Update #2: I'm now collecting data, I think. The step I was missing was that I needed to Publish a new version of the container *after* adding the tag and trigger. In other words, it is not sufficient to add the tag and trigger without subsequently publishing a new version of the container. Steps to publish a container...
1) Go to https://tagmanager.google.com
2) If necessary, make sure you are in the right Google account by clicking on the profile icon in the upper right corner of the UI and selecting the appropriate Google account (if you have more than one).
3) Click on the container you want to publish.
4) Click the blue "Submit" button that appears on the far right portion of the header bar.
5) Enter a version name and description and then click the blue "Publish" button.
Done. The latest version of the container is now published.
Note that this part of the README is outdated: "For development purposes, create a GTM environment for your website and enter the 'environment ID' on the 'Advanced' tab of the settings form." The "Advanced" tab doesn't exist anymore. Granted, Google changes its UI often enough that it's understandable the README would get out of sync with the latest Google UI changes.
Update: I am actually not collecting data. Even though Google's "Preview" feature suggests all is well, after waiting several days I still do no see any data collected in my GA4 web property.
I still do not know how to confirm whether I've installed the google_tag module correctly. It's quite possible I have, but because of the vagueness of the README, I'm not sure. Just a little bit more specificity in the README would allow me to confirm that I have installed the module correctly. It wouldn't take much.
When I follow the path in your edited README, I see a Stream ID and a Measurement ID. See attached screenshot. Please consider using the precise terminology to avoid confusion. There is no such thing in Google as a "G-code". That is informal terminology that is not used in Google's UI.
I don't understand why you are leaving "Google Analytics account number" in the file. Why not state specifically what you mean? That is, if you mean Stream ID, say that. If you mean Measurement ID, say that.
Thanks
I'm not sure about Drupal 8, but in Drupal 9 you can do this in the view settings. Open the Header or Footer settings for the view and search for Global: Result Summary.
This is not a bug. I misunderstood how the views display settings are applied. The opportunity to choose between "All displays" and "This block" only comes when we choose the format. If we choose "All displays" at that point, then any changes to the settings for that format will also apply to other displays (that haven't been overridden). This is normal behavior for Views.
The "fix" in my cases is to change the format to something other than Slick Carousel, and then apply and save, and then change the format back to Slick Carousel -- at that point we have the opportunity to choose "This block" so that subsequent settings changes won't affect the other displays.
I think I just found the issue. I'll provide more information shortly.
"You must select Apply"
Yes, of course. I am clicking Apply and then saving the view after each configuration change. This is not a case of user error :)
I installed the Slick Example view. However, this view does not prove the bug doesn't exist. It only proves there are situations where it doesn't happen. But the bug is easy to reproduce. I have provided clear steps to reproduce the bug, and am able to reproduce it myself, over and over. It only takes a minute to create a view that reproduces the bug. Please follow the steps I've provided.
My Drupal core version is 9.5.7.
arnoldbird → created an issue.
arnoldbird → created an issue.
I'm also seeing this error in the console. My situation is the same as #5. Carousel works fine but I get the error in the console when I'm logged into Drupal. I also have bigpipe installed and my Drupal version is 9.5.7.
When bigpipe is uninstalled the error goes away.
arnoldbird → created an issue.
I found a configuration that works. If I turn on "center mode" for my smallest breakpoint, the number of dots is correct and it is possible to navigate to the last slide.
Leaving this issue set to "bug," because "center mode" should probably never affect whether or not the correct number of dot elements are provided in the HTML output.
Changing this back to bug as I am still finding it breakable in Chrome/Edge, and totally unbreakable in FF. In my present configuration, at the lowest breakpoint, in Chrome/Edge, the wrong number of dots is displayed and it is impossible to navigate to the last dot. The HTML itself is wrong at my 640px breakpoint -- it has elements for three dots when there should definitely be five, as there is in FF.
To be clear, I am totally unable to break the library in any browser, and am unable to break this module in FF. However, the module is breakable in Chrome/Edge.
Changing this back to support request for the moment, because I'm no longer seeing different behavior in FF vs Chrome. Previously, FF was working well in my component, but it wasn't working in Chrome. Now, neither works well.