#2 and #6 are identical - moving back to RTBC.
I also came here due to the google_tag problem. I think this issue should be reopened, so I'm reverting the status back to Needs Review.
Hmm, using FileSystemInterface
alone didn't seem to solve the problem - the FileSystemInterface::realpath method returns false.
From the Drupal API documentation:
The use of this method is discouraged, because it does not work for remote URIs. Except in rare cases, URIs should not be manually resolved.
Yes and yes.
I was looking at the code, and noticed in /src/WebformSubmissionExporter.php on Line 872, the FileSystemInterface::realpath method is used. From the Drupal API documentation:
The use of this method is discouraged, because it does not work for remote URIs. Except in rare cases, URIs should not be manually resolved.
I wonder that might be the reason why it doesn't work with s3fs?
Yes, that is correct - the s3fs → contrib module is used.
andrew.wang → created an issue.
andrew.wang → created an issue.
#50 works +1
https://git.drupalcode.org/project/drupal/-/merge_requests/10859.diff solved this issue for me after installing entity_reference_integrity on Drupal 10.3.10.
https://git.drupalcode.org/project/drupal/-/merge_requests/10896.diff also worked!
Thanks for the clarification that this issue is regarding the entire site!
I initially suspected it because it’s weird that it always times out the first time when I visit the dashboard in Firefox (i.e. when Drupal.org is opened in a new tab), but a refresh always fixes it, and it works fine in any other browsers. Anyways, thanks for the information!
Not sure if this is related, but I'm starting to see this quite often recently:
This appears to still be an issue in Drupal 10.3.10 / PostgreSQL 16.1.
Came here from Google - just want to report that I got bitten by this too.
andrew.wang → created an issue.
Tests are passing. Moving to RTBC!
PS: We should probably set up CI so running tests would become easier.
andrew.wang → created an issue.
This discussion seems to be getting spicy... In the spirit of constructive criticism, here's my take on the new design - first thing first, yes, I hate it too.
Six years ago, the place I worked at hired an agency for a new visual identity. I didn't like it, but I had no say in design so I just kept quiet and complied. Fast forward to today, when I saw the new Drupal.org design, it instantly gave me flashbacks from six years ago - it uses almost the same set of design elements from that design by the agency - logo broken into parts, logo zoomed in to be used as supergraphic, with stock photography of happy people filled into the supergraphics, you name it... It feels exactly the same, just a different logo.
What irks me the most is that the new design seems to has lost the soul of Drupal. I really like what @amazingrando said in #127 - the new site still feels valid if you replace every instance of "Drupal" with "WordPress". Heck, it even doesn't look too weird if I replace "Drupal" with "UnitedHealthcare" - guess what, their home page is also filled with stock photography of happy people...
When I go to apple.com, I see a giant picture of an iPhone; when I go to react.dev, I see pictures and examples that give me an ideas of what using React feels like; but when I go to drupal.org, all I see is just stock photography of happy people, testimonials and big numbers. How do I know if Drupal is what I need without seeing the actual product? So Drupal, please show me the damn thing!
Confirming patch #92 works on PHP 8.3.10 / Drupal 10.3.10.
andrew.wang → created an issue.
I came here from Google - seems this is still the case in Drupal 10.3.10.
I found
https://www.drupal.org/node/3013865 →
and
https://www.drupal.org/project/drupal/issues/1154180 →
, but path alias still doesn't seem to show up when comparing revisions using the diff module.
There seems to be a white margin on the right on mobile (iPhone 13 mini, iOS 17.7.2)?
If you can’t see it the first time, try doing the zoom out gesture and the white margin appears
There are still many projects that do not have an automated Drupal 11 readiness issue created. For example, both masquerade_field → and openid_connect_windows_aad → do not have an "Automated Drupal 11 compatibility fixes" issue.
andrew.wang → created an issue.
Been using the patch in #9 for 2 months. It works great.
Looks good now after applying the patch:
Very straightforward patch. Looks good to me.
I encountered the same issue - header check is always failing for my basic auth protected site:
However, this looks like a WordPress site?
andrew.wang → created an issue.
FWIW, full screen mode is already provided in the official CKEditor 5 Plugin Pack as a “premium plugins available for free”: https://www.drupal.org/project/ckeditor5_plugin_pack →
I see @joco_sp can now opt projects into security advisory coverage - moving this issue back to Drupal.org project ownership.
@joco_sp maybe try opening a new issue for maintaining offer? This issue is already closed so it likely won't get any attention.
I second that this issue might be unrelated to #3384400, which is about CKEditor 5 mangling an existing table that might already have the scope
attribute in the markup.
On the other hand, this issue is an accessibility issue and can be reproduced from scratch, without any existing markup. CKEditor should automatically add the scope
attribute to <th>
elements for accessibility reasons when defining a row or column as header using the toolbar. This used to work in CKEditor 4, but is absent in CKEditor 5. Although we can go to source mode and add scope
attribute to <th>
elements manually, tables with header rows and/or header columns created using only WYSIWYG are by default inaccessible.
In addition to the GitHub comment mentioned in #5, there’s a separate upstream issue about this accessibility issue on GitHub: https://github.com/ckeditor/ckeditor5/issues/3175
RTBC+1
The aforementioned upstream issue is now marked as completed!
Fixed some typos from #25.
I didn't review the code but just wanna report that #179 works well for me on a big site running Drupal 10.2.1!
Tested using simplytest.me with this patch applied to the 4.0.0-alpha1 branch on Drupal 10.2.0. The toolbar icon does not seem to reflect /js/plugins/abbr/icons/abbr.png?
andrew.wang → created an issue.
andrew.wang → made their first commit to this issue’s fork.
I ran into this issue too. Before applying the patch, Drupal does not bootstrap and I see error as shown in the screenshot. After the patch, the error is cleared. RTBC +1.
I found a typo on the now launched landing page. I came across this issue through a search and hope that this is the right place to report!
On https://www.drupal.org/about/drupal-7/d7eol/partners#type-simple → , there’s a sentence that reads the following:
If your need is truly a node code solution that can be as basic as a simple online brochure
Shouldn’t it be “no code” instead of “node code”?
andrew.wang → created an issue.
andrew.wang → created an issue.
andrew.wang → created an issue.
I’ll try contacting the maintainers for a release.
andrew.wang → created an issue.
+1. Kindly requesting a tagged release :-)
I second #12 - the patch has been applied to the site I'm working on for 2 years and it's been working great on a high volume website.
(Disclaimer: Nick and I work at the same organization but a different site ;-P)
In my site, I had to downgrade to 0.15.13 instead of 0.15.18 for some reason.
Tried panels
with the same method as #14 and I can reproduce the same behaviour.