https://www.drupal.org/project/drupal/issues/2899338#comment-15774058 🐛 Wrong render of HTML from label when field is shared across languages in error message Needs work
It appears that this issue has been resolved in the latest version of Drupal 11.
Not everyone is on 11.x yet... This is rerolled for 10.3.x.
6 YEARS ...
Well, I guess you could do this now:
$languages = array_map(fn ($language) => $language->getName(), $this->languageManager->getLanguages());
It doesn't seem like it matters though, if they haven't merged it yet - unlikely they'll merge it in the next 6 years either.
can we consider merging with the 4.1.1 release and publish it on the module project's page too?
I've tagged it for 4.1.2, but no - I won't publish it on the modules project page. This module isn't supported anymore; it is marked as "Seeking new maintainer"/ "No further development" as I don't work for Rackspace anymore and have no interest in maintaining it.
No need for sorry! D9 is unsupported now, so there's no need to accommodate "backwards-compatible" functionalities. I'm pretty sure we're breaking D9 compatibility with some of these changes anyway ... and with that in mind, my turn for a "sorry" - sorry ... but I think maybe I'm not being clear at all with my post above.
94x: Symfony\Component\EventDispatcher\Event is deprecated in drupal:9.1.0 and will be replaced by Symfony\Contracts\EventDispatcher\Event in drupal:10.0.0. A new Drupal\Component\EventDispatcher\Event class is available to bridge the two versions of the class. See https://www.drupal.org/node/3159012 →
There's no need to use \Drupal\Component\EventDispatcher\Event at all - if anything, it's more likely to be removed given it's bridging a deprecation for an older version of D9 (which as I say, is no longer supported by a VERY long way).
I was trying to say, don't use the Drupal one - you should just use the \Symfony\Contracts\EventDispatcher\Event class instead.
Rolling both these issues into one ticket.
I linked to https://www.drupal.org/project/drupal/issues/3055198 📌 [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead Fixed in https://www.drupal.org/project/web_page_archive/issues/3446369#comment-1... 🐛 Drupal 10 compatibility fixes Needs review
This is the fix for the deprecation, I'm not sure why you both ignored my comment.
Also, you might want to drop support for D9 in this. I very much doubt this maintains compatibility.
Nice, RTBC as well. I'd forgotten all about this!
This can be closed as a duplicate now, updating the cache tags was always the answer.
You know ... this is kind of hilarious. I had to evaluate this module recently and had no recollection of working on it personally. It's only seeing this issue come through on my email that reminded me that I was part of the team who originally wrote it!
Anyways, many thanks - I've added you.
You've merged the wrong one ... You've picked the patch which doesn't use any Dependency Injection...
Just FYI here, by default (and intentionally), APCu isn't enabled for CLI - as it doesn't make sense to be there when using it. You're seeing this error because Drush is obviously CLI, so APCu is off/ not present. That's why it works fine in the web interface.
I don't feel like we should be supporting PHP7.x any more, it's well beyond EOL now, as is PHP8.0.
Use Google: https://www.drupal.org/project/drupal/issues/3055198 📌 [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead Fixed
I did report it to them 9 months ago when I raised this issue. It took them two months to reply, and basically, they shrugged their shoulders and said they didn't care at all. This is simply here for somewhere to host the patch.
As for me, I don't consult for the company that needed the patch any more. So it makes zero difference to me.
As I was saying in #53, we have AssertPageCacheContextsAndTagsTrait available here - how would you feel about changing the test from say;
/**
* Verify that the cache-control header is added by FinishResponseSubscriber.
*/
public function testCacheabilityOfRedirectResponses() {
$config = $this->config('system.performance');
$config->set('cache.page.max_age', 300);
$config->save();
$this->getSession()->getDriver()->getClient()->followRedirects(FALSE);
$this->maximumMetaRefreshCount = 0;
foreach ([301, 302, 303, 307, 308] as $status_code) {
foreach (['local', 'cacheable', 'trusted'] as $type) {
$this->drupalGet("/system-test/redirect/${type}/${status_code}");
$this->assertResponse($status_code);
$this->assertHeader('Cache-Control', 'max-age=300, public');
}
}
}
To something like;
/**
* Verify that the cache-control header is added by FinishResponseSubscriber.
*/
public function testCacheabilityOfRedirectResponses() {
$this->enablePageCaching();
$this->getSession()->getDriver()->getClient()->followRedirects(FALSE);
$this->maximumMetaRefreshCount = 0;
foreach ([301, 302, 303, 307, 308] as $status_code) {
foreach (['local', 'cacheable', 'trusted'] as $type) {
$this->drupalGet("/system-test/redirect/${type}/${status_code}");
$this->assertResponse($status_code);
$this->assertCacheMaxAge(300);
}
}
}
It needs a bit of rewriting now too, as we have AssertPageCacheContextsAndTagsTrait for enabling and checking headers. Might as well use it.
If I get time later on I'll do it...
Here's what I ended up doing:
sub vcl_recv {
# Check if this is one of our sites in maintenance mode.
if (
req.http.host ~ "^(www\.)?drupal\.org$"
) {
set req.http.X-Maintenance-Mode = "true";
}
}
sub vcl_backend_response {
# Check if we're in maintenance mode.
if (bereq.http.X-Maintenance-Mode) {
set beresp.http.Cache-Control = "public, max-age=86400";
unset beresp.http.Set-Cookie;
unset beresp.http.X-Maintenance-Mode;
set beresp.ttl = 1d;
}
}
Ugh ... I'm just going to have to do this in Varnish instead. So much for Drupal being flexible.
Ugh ... okay - that's annoying. Seems this isn't possible without overriding the entire service as it contains;
\Drupal::service('page_cache_kill_switch')->trigger();
And it doesn't look like that's able to be reverted :( Lemme think about it, maybe there's another way ...
edit: I admit I'm maybe a niche case (long-term parking of domains) but this should still be possible IMO.
I'm marking this as for review ... but I haven't even tested it myself yet...
Y'all broke my unit tests! This corrects that the Views filter schema was updated but not the sort schema.
This is just a reroll, no interdiff as it's purely for getting my build working again (the test needs rewriting).
Have removed the test changes in MenuUiNodeTest as this is why it's failing.
I'm afraid it's still going to need a specific test though.
Plus, see this previous comment:
Since the formatted version is what is getting sent to Akamai, the mb_strlen($tag) check needs to occur after the formatting, not before.
Reroll as #4 failed to apply.
Hiya!
I've left it with Acquia (who I don't mind saying, were really useless with it) - but yes, there are three solutions.
1. You can convert your acquia_cms profile to instead be the "minimal" profile.
That way the dependency will come from your own core.extension.yml and not the acquia_cms profile.
2. If you do need/ use purge_processor_lateruntime, edit the acquia_cms_common.install file to:
/**
* Implements hook_update_N().
*
* Uninstall Late runtime processor module.
*/
function acquia_cms_common_update_8007() {
// Just mark this update as having been "run". This way it won't be run again.
}
3. If you don't need the purge_processor_lateruntime module installed, edit profiles/contrib/acquia_cms/acquia_cms.info.yml and remove this line:
- purge:purge_processor_lateruntime
Hmmmm maybe I phrased it badly, but I really just meant to say that I had no idea what the purpose of the 5.x branch is - and that I'm not aware of any roadmap issue ticket existing to explain why it exists. As in, this view doesn't help with that: https://www.drupal.org/project/issues/akamai?text=&status=All&priorities... →
In my view, changing to a branch new major release version is for a rewrite. But sure, it could also be for D10 compatibility - I just didn't immediately see any information about it really to know whether the patch created here was even applicable.
I have no idea why the 5.x branch exists. There's been no communication about it, as far as I'm concerned it's a fork and I have no clue what the intention is for it. In which case, you'll need to raise a separate issue for 5.x - note that the patch here broke another test, so when you make another patch, please be sure to add the fix I made too.
That's great, thank you very much.
If you could please correct this:
'#title' => t('Cache Tag Prefix'),
Which should be using $this->t()), I'll see about merging this tomorrow.
Hmmmm... I don't have a local version, this isn't clearing it - but I can see why. Will fix soon.
The patch at #3 📌 Automated Drupal 10 compatibility fixes RTBC needs work, it should be using DI in class files - and not reference the services directly.
pobster → made their first commit to this issue’s fork.
Uhhhh thanks, but you seem to have your CS set up weirdly - the only genuine ones on here are;
FILE: ...w/html/app/web/modules/custom/site24x7/src/Form/SettingsForm.php
----------------------------------------------------------------------
FOUND 3 ERRORS AFFECTING 3 LINES
----------------------------------------------------------------------
23 | ERROR | [x] Expected 1 blank line after function; 2 found
34 | ERROR | [x] @inheritDoc found. Did you mean {@inheritDoc}?
80 | ERROR | [x] @inheritDoc found. Did you mean {@inheritDoc}?
----------------------------------------------------------------------
PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------
The bottom two are because PHPStorm oddly defaults to that when making method stubs :(
I'm afraid I can't merge your patch as-is, as I'm going to change the JS today more than likely. And ... also you have some mistakes here, namely all the javascript ones: https://www.drupal.org/forum/support/module-development-and-code-questio... →
Looking specifically at 2. there:
> 2. TRUE, FALSE, NULL are not valid in JavaScript and their lower-case equivalents must be used instead.
I'm going to close this as this is a development version for a reason. I only pushed it late last night, I mean - I haven't even tested it at all yet.
Trying this out. And, I only care about the required mark for my task. I'll look at the newer duplicate ticket later.
Re-rolled #25.
8.x-1.x has a commit in it now meaning this patch doesn't apply. Rerolling, as the change to CKEditorResize.php has not been made.
Ha! Oops! :D
Hiya! Yeah, still there - the team is very small these days! Hope you're doing well :)
Just noting you now get;
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.User
* The API key field needs to be uninstalled.
...when the module is uninstalled.
Something else you could include here is that the config schema file at config/schema/field_group.field_group_formatter_plugin.schema.yml is missing an entry for direction.
pobster → created an issue.
Just an FYI, there's no need to generate patches - you can just generate one from the VCS, by sticking .patch to the end of the commit hash.
https://git.drupalcode.org/project/xmlsitemap/-/commit/f7122db.patch
There is a lot of information out there already on this, take a look at: https://drupalsun.com/ztl8702/2016/05/17/retrieving-entities-mongodb-dru... Which I believe is doing what you're trying to achieve?
IMO, it is going to save you an awful lot of time to just use the MongoDB module instead but only you know all your requirements (I mean, why do this at all?) For reference see: https://fgm.github.io/mongodb/