🇭🇺Hungary @Gábor Hojtsy

Thanks a lot! Test looks good to me, I think this is fine :)

Updated the issue summary with that explanation. I think this makes sense.

Is there a straightforward way to add a test for this? :)

gábor hojtsy → changed the visibility of the branch 3443833-provide-a-way to hidden.

Hm how does the MR without the hooks solve the extensibility then?

We ran into this at ✨ Provide a Config Action to add/edit a component in a layout Active . This would be a much better way to resolve it than to add to the baseline there :D Such great diffstat also :)

Which MR is to be reviewed?

Hm, the current code in the 10113 MR seems to be moving the logic around but does not actually make it extensible yet? What am I missing?

The other MR adds a new hook and hook_alter.

Reached out to phpstan folks. Learned that 🐛 Add missing @return types for StringTranslationTrait::formatPlural() and ::getNumberOfPlurals() Active is in the way, until that lands, the phpstan baseline needs updating in the MR.

As a core product manager I think this makes sense. It allows us more flexibility in the future to possibly remove the big UI for example from core if we think its not an 80% use case even if content moderation or node preview is.

Only minor note is the description of the original module now does not reflect what it does? The module does not provide full site previews after this MR.

Allows users to stage content or preview a full site by using multiple workspaces on a single site.

This is minor IMHO but would be still useful to fix to make it easier to understand what's the relation between the two modules. But leaving needs review for more reviews as appropriate.

Although you are linking 📌 [META] Track 15: Proposal for media management Active , I believe the description of your intended result is on 🌱 Proposal for Media Management in early versions of Drupal CMS Active , right? Do you have a checklist/summary of how much did you implement from that in this MR?

The MR only seems to add the "add layout component" action, so I think its far that it only has tests for that. @phenaproxima indicated that these improvements to the tests would be good, that still looks like needs work:

• We need to be sure the region stuff works as expected, including when the default region is used, or the region can't be resolved.
• We need to be sure the position stuff is figured out correctly, every way it could be passed in.
• We need to be sure that the additonal key is preserved if passed.
• The test...isn't using config actions. That obviates the entire point of this MR. We need to test that we can accomplish the addition of the component using config actions. (We don't need to use a recipe, but we probably need ConfigActionManager::applyAction(...).

kristen pol → credited gábor hojtsy → .

Unassigning for now, since Matt does not have time anymore for this unfortunately.

gábor hojtsy → created an issue.

Are there specifics to update other than the outdated screenshot? :)

I somewhat share the default content concerns, although I believe it would be nice to have a way to automatically generate a default legal notice to start working with. However the current default content designates "Drupal CMS" as the responsible legal entity and is full of mentions of Drupal being responsible for stuff, so that is a no-go to ship with I think :) (On top of the grammatical issues in the text).

Data protection is of a particularly high priority for the management of the Drupal. The use of the Internet pages of the Drupal is possible without any indication of personal data; however, if a data subject wants to use special enterprise services via our website, processing of personal data could become necessary. If the processing of personal data is necessary and there is no statutory basis for such processing, we generally obtain consent from the data subject.

xjm → credited gábor hojtsy → .

I think text format editor, content type, taxonomy, etc. type of a recipe would not appear as a site or a kit, so at best it would be a subtype of a foundational recipe (if recipes want to do subtyping that is). Would be great to run the three types through the initiative meeting and get feedback there. Then move forward to codify this as it would help move with project browser's listing.

📌 Decide and update recipe naming and classification standards Needs review has a decent three legged proposal for types, let's discuss there if there is anything in the way to adopt that :)

@carsoncho: I like those three levels, we should codify the type naming for them, so that tools like drupal.org's API endpoint can properly expose them and Project Browser can offer a UI to find them (or hardcode filters for them). What's in the way to codify this?

Does this mean recipe types are not anymore intended to be documented? :)

Interface Translation (locale) in core uses the project and version identification feature of Update Status. (Also Upgrade Status and Upgrade Rector do the same as well as probably a bunch of other modules).

Indeed, good point! I think renaming the existing one's human readable name back to Update Status is a good way forward. Internally it reflects that naming already.

Update Manager sounds good and is in line with the rest of the core and contrib features in this area. Also with Package Manager.

Saving notes, thanks all!

Saving notes

Meeting parser fails at the celebrations thread. Need to figure out why, then can save the notes.

Fixing credit for James. Thanks all!

Thanks all!

gábor hojtsy → created an issue. See original summary → .

Googling for that specific error message it comes up from https://www.drupal.org/forum/support/module-development-and-code-questio... → , looks like you either use that custom module or someone very strongly got inspired by that code (copy-pasted it). This would be output when that code is run (since it echos and dies). The container in this case is not yet initiatialized because the error happens in a global context while the codebase is being assembled. Look at your own site codebase to find this code.

Is this included in the error like this?

No! This is not for you! Your Drupal installation does not support utf8mb4. Have a fruitless look at https://www.drupal.org/docs/7/api/schema-api/data-types/encoding-collati → ... and then forget this module."

Released in https://www.drupal.org/project/upgrade_status/releases/4.3.6 → , please try there and let us know if the errors persist.

Thanks!

gábor hojtsy → made their first commit to this issue’s fork.

Merged the MR to report the fail from drush so errors are surfaced earlier and in a more useful way.

My comment in #4 still stands that this undoes the reporting that there may be deprecated API uses that cannot be detected because its not enabled, given the hasImplementations() will not find the hook if the module is disabled and thus the patched code will return no errors.

I added that category.

The module already had the Developer Tools category which I kept.

The tests pass fine on the simple ignore fix now I think given the core fixes. We can merge that in to stop the bleeding on older core versions too without changes needed to the tests.

Added some related issues.

I believe 📌 Twig Filter "spaceless" is deprecated Active is still outstanding but otherwise this is resolved in core and fixes were released in patch versions of core.

Merged the MR. Will release 4.3.6 with this and a couple other fixes soon.

The MR should remove the drupal_root from phpstan-drupal config. The other errors I don't believe come from Upgrade Status :)

gábor hojtsy → made their first commit to this issue’s fork.

xjm → credited gábor hojtsy → .

longwave → credited gábor hojtsy → .

You are right, I made Drupal CMS a lot more prominent on the project page, hope this helps :)

Add Drupal 10 end of life. Expand Drupal 7 end of life info.

We discussed this with Lauri yesterday as Drupal core product managers. We have no concerns. The added code does not have UI parts other than some error messages which seemed fine. Two modules already integrate well with it and we agree the product needs it for both. Being an API module, we accept the judgement of the framework managers on the APIs.

I created the Drupal 11 video with some of the above in mind (establish Drupal as a trusted name, highlight wide contribution, etc) and then get onto the benefits of Drupal 11 itself. I did not use a voiceover for simplicity.

I think if we want to have voiceover for this one, we want to have a video with music + voiceover. Is there a good distribution mechanism that is editable for this? Or we'll use one person's copy / computer to receive and edit the translated voiceovers in? Or distribute the music alongside the video for the local associations at least?

Those cards look great! I use Google for my searches and never seen that :) I agree adding this would be great, and I think @drumm already outlined that the Drupal 10/11 version of events could receive that later on :) The Drupal 7 version of the site is currently on life support.

Does core do the same? It does not help much if we parse those files, if core does not do it :)

gábor hojtsy → created an issue. See original summary → .

Neither sample searches provided showed me event cards. How would those look like when they show up in Google?

bramdriesen → credited gábor hojtsy → .

bramdriesen → credited gábor hojtsy → .

bramdriesen → credited gábor hojtsy → .

bramdriesen → credited gábor hojtsy → .

Thanks for opening the issues. I neglected to do that when scheduling them.

gábor hojtsy → created an issue.

The referenced core issue and above that 📌 Fix Twig 3 deprecations Needs review is where we are actually fixing the core issues that cause this, so Upgrade Status should not fix this for now. The plan is a bugfix release of core soon will fix this. Postponing on that for now.

These were the top errors found in contrib by Project Analysis:

• 177 765 times (in 1324 projects): Since twig/twig 3.12: Getting node "filter" on a "Twig\Node\Expression\FilterExpression" class is deprecated.
• 10734 times (in 641 projects): Since twig/twig 3.12: Not passing an instance of "TwigFunction" when creating a "render_var" function of type "Twig\Node\Expression\FunctionExpression" is deprecated.
• 1080 times (in 209 projects): Since twig/twig 3.12: The "tag" constructor argument of the "Drupal\Core\Template\TwigNodeTrans" class is deprecated and ignored (check which TokenParser class set it to "trans"), the tag is now automatically set by the Parser when needed.
• 1100 times (in 274 projects): Since twig/twig 3.12: Getting node "filter" on a "Twig\Node\Expression\Filter\RawFilter" class is deprecated.
• 864 times (in 121 projects): Since twig/twig 3.12: Getting node "filter" on a "Twig\Node\Expression\Filter\DefaultFilter" class is deprecated.
• 512 times (in 147 projects): Since twig/twig 3.12: Twig Filter "spaceless" is deprecated. See https://drupal.org/node/3071078.

Are these all being resolved in the children? :)

Also these two were found in one project each, not a priority IMHO:

• Since twig/twig 3.12: Character """ at position 2 should not be escaped; the "\ character is ignored in Twig v3 but will not be in v4. Please remove the extra "\" character." in formatage_models 4.x-dev
• Since twig/twig 3.12: Character "T" at position 7 should not be escaped; the "\ character is ignored in Twig v3 but will not be in v4. Please remove the extra "\" character." in festeva 1.0.x-dev

Imo we shouldn't just `fix deprecation message` here. But fix deprecations deeper, with research of new twig extending style. This issue is RTBC of course. But - can we do it better? Idk yet.

I think it would be great to have a "good enough" solution ASAP, and then spend any time to fix it even better later. Because these deprecated API uses produce errors with most runs of Upgrade Status on all contrib projects and people can't do anything about it. When we ran Project Status on all contrib modules, these produced 190 thousand twig deprecacted API calls detected across all of Drupal 10 contrib :) This also means that none of those are getting project update bot patches/MRs because they have these unsolvable issues. So a quick solution would be important to unblock the rest of the ecosystem / tooling, then a better solution is not out of question :)

Retitled for that scope then. Should we open an MR in an another issue or conver this to a core issue?

Should 📌 Fix "Twig\Node\Expression\FilterExpression" deprecation introduced in twig/twig 3.12.0 Active be directly solved in this issue or remain in its own?

xjm → credited gábor hojtsy → .

Indeed that error message is not helpful. Could the error be more specific and tell the user the directory does not exist? What can the user then do to get the directory created? (Save the file settings config form?) At least if we let the user know this, they have a chance to sync their translation files if they wish so without silently getting them into a different situation.

Uh the tests are also getting caught up with the twig problems, they need to be updated to expect them in an "ignore" category.

We also noticed 190k or so of these errors with twig 3.12 across scanning all of contrib with Deprecation Status. Since the error (almost?) always come from core not being compatible, we should not burden users with trying to figure this out. I proposed an MR here that puts the error in the "ignore" category. It is not required to resolve twig 3.12 incompatibilities anyway to be compatible with Drupal 11 :)

gábor hojtsy → made their first commit to this issue’s fork.

Ah right, good point. I would try composer why-not https://laravel-code.tips/use-composer-why-not-to-see-why-a-dependency-c... on symfony/css-selector ^4.4

How is your problem related to Upgrade Status?

Thanks for starting on this! "Within the core committer team", "while core committers", etc. still has the old terminology.

xjm → credited gábor hojtsy → .

So the text is not in line with the requirement?

    elseif ($database_type == 'sqlite') {
      $database_type_full_name = 'SQLite';
      $requirement = $this->t('When using SQLite, minimum version is 3.26');
      if (version_compare($version, '3.45') >= 0) {
        $class = 'color-success';
      }
      else {
        $status = FALSE;
        $class = 'color-error';
      }
    }

I see it here.

Approved from core :)

Absolutely should be done :)

Moving the localization server which is where the error shows up. Can you not save it or "just" an error shows up but you can still save it?

Moving to Drupal CMS

Moving to Drupal CMS