Hungary
Account created on 28 September 2003, over 20 years ago
  • Initiative coordinator coordinator at Acquia 
#

Merge Requests

More

Recent comments

🇭🇺Hungary Gábor Hojtsy Hungary

Looks good IMHO. Fits with the existing command. Merged.

🇭🇺Hungary Gábor Hojtsy Hungary

Yay! Great feature. I think "View file on ..." would be the proper English not "in"? Otherwise UI looks good. Did not review the code in detail.

🇭🇺Hungary Gábor Hojtsy Hungary

Aw, this sounds great :) We should have some test coverage added too.

🇭🇺Hungary Gábor Hojtsy Hungary

Made them available under https://www.drupal.org/about/starshot/marketing for now since there are more there now :)

🇭🇺Hungary Gábor Hojtsy Hungary

I have mixed feelings about this issue.

I think the missing translation directory in your dev situation for example is a lack of syncing files in your development workflow. Other critical files may also be missing. Eg. the JS translation files may get regenerated locally and that may end up leading to a mismatch in your live site when the updates get pushed (depending on what you push).

At the same time I understand the developer experience improvement that instead of an error, you get an empty directory at least. I am not sure though if that does not lead to unwanted side effects.

How are other files missing handled by Drupal? Eg. if your site logo is missing or other key files that you don't have on the dev environment?

One MR specific comment: How is the locale/src/Plugin/QueueWorker/LocaleTranslation.php change related?

🇭🇺Hungary Gábor Hojtsy Hungary

They could here at least as though we can add them to other d.o pages (which I did from them being hosted here). But yeah we need a nicer way to host / offer them. There is also a slide deck template we'd like to provide that blends the Starshot and new Drupal branding and was used in the product session.

🇭🇺Hungary Gábor Hojtsy Hungary

@Balu Ertl: I think that's an entirely separate question :) Retitled this from the original suggestion to the consensus. :)

🇭🇺Hungary Gábor Hojtsy Hungary

How is this reviewed and tested, what did you do to review and test?

🇭🇺Hungary Gábor Hojtsy Hungary

I agree with Lauri and others above. Unfortunately the internet became a place where you need to set up extensive protections to even attempt to enable user registration publicly. :/ Most of those don't come with core so you may be in for some nasty surprises before you may have a chance to set up the tools to avoid it.

🇭🇺Hungary Gábor Hojtsy Hungary

These don't seem to appear in the deprecation status info though? These two appear but they will not match the strpos() proposed:

Call to deprecated method loadRevision() of interface Drupal​\​Core​\​Entity​\​EntityStorageInterface. Deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use Drupal​\​Core​\​Entity​\​RevisionableStorageInterface::loadRevision instead.

Call to deprecated method deleteRevision() of interface Drupal​\​Core​\​Entity​\​EntityStorageInterface. Deprecated in drupal:10.1.0 and is removed from drupal:11.0.0. Use Drupal​\​Core​\​Entity​\​RevisionableStorageInterface::deleteRevision instead.

Is deleteRevision not affected by the same situation?

🇭🇺Hungary Gábor Hojtsy Hungary

The explicit inclusion of non-Drupal rectorable items will need some adjustment in deprecation_status since we consider the rectorable ones are Drupal, but that should not stop from improving this. I can catch up later there.

🇭🇺Hungary Gábor Hojtsy Hungary

But getDrupalCoreMajorVersion() is the current version we are on. Do we not want to start reporting it on Drupal 11 expecting Guzzle 8 would be out before 2026?

🇭🇺Hungary Gábor Hojtsy Hungary

Is this roadmap still current or is there a better one?

🇭🇺Hungary Gábor Hojtsy Hungary

I think we need a "don't have an icon" icon yes. The mockups from the Starshot wireframes are not necessarily indicative IMHO of what we should end up with, that's up for definition. The icons will show up in a card type of interface too, since project browser will offer recipes in the full UI of project browser later in the site's life.

🇭🇺Hungary Gábor Hojtsy Hungary

That's not the only place where Drupal appears. Eg. https://git.drupalcode.org/project/drupal and https://www.drupal.org/project/drupal . We'll likely not use in marketing but the underlying core will have a different release cadence and versioning than "Starshot", so for the sake of referring to the two of them we need some kind of naming scheme. At least both of them can't be called "Drupal".

🇭🇺Hungary Gábor Hojtsy Hungary

I can see a difference between "it made sense to break it down like this for code reuse" vs "this is a level of feature that makes sense for users". I think the later would need icons, the former I would not make people do icons, if they show up on the UI they could be very overwhelming. Eg. the full list of current core recipes is not all something the user level would expose I think. Maybe a (very) advanced setting.

🇭🇺Hungary Gábor Hojtsy Hungary

I think we need some kind of differentiation as to which ones would show up on the UI and which ones are too low level. Then we don't need the icons for the low level ones.

🇭🇺Hungary Gábor Hojtsy Hungary

I think generalizing it is confusing, because once Drupal 11 is out, "next major version of Drupal" will be Drupal 12 immediately :P So possibly removing it is a better idea.

🇭🇺Hungary Gábor Hojtsy Hungary

Adjust height

🇭🇺Hungary Gábor Hojtsy Hungary

That wide logo looked awkward with the text. We currently only have the Drupal logo but no displacement, so here is the new one with proper displacement too. Ran through imageoptim.

🇭🇺Hungary Gábor Hojtsy Hungary

Created a copy of the logo with the proper displacement in white, so we can replace it.

🇭🇺Hungary Gábor Hojtsy Hungary

I released https://www.drupal.org/project/upgrade_status/releases/4.3.2 with support for checking for this one specific key deprecation. I don't think we have a generic way to statically detect config keys depreacted but would be happy to add support for that too there for a more general solution.

🇭🇺Hungary Gábor Hojtsy Hungary

The internal check was excluded just now explicitly in Disable ClassExtendsInternalClassRule Needs work . This would still apply to other baselines.

🇭🇺Hungary Gábor Hojtsy Hungary

Via @berdir:

something that I'm seeing pop up a lot in contrib tests is the removal of default_argument_skip_url, I've had that in ~3 out of 5 modules that I've worked on so far. It's key in a yml file, not sure where exactly detection of that would go

[...]

well, config schema validation fails
so the test fails

https://git.drupalcode.org/search?group_id=2&scope=blobs&search=%22defau... finds 1500 instances of this

So it looks like the fallout from this is much bigger than expected.

I am working on 📌 Support default_argument_skip_url views setting removal checking in Upgrade Status Active to side-add a deprecation for this in upgrade status at least. But based on that contrib search many more people will run into this.

🇭🇺Hungary Gábor Hojtsy Hungary

Should we add a drush filter argument to Upgrade Status that project analysis can use? Upgrade Status already deemphasizes future deprecations. This code https://git.drupalcode.org/project/upgrade_status/-/blob/4.x/src/Depreca...

    // If the deprecation is already for after the next Drupal major, put it in the
    // ignore category. This overwrites any categorization before intentionally.
    if (preg_match('!(will be|is) removed (before|from) [Dd]rupal[ :](\d+)\.!', $error, $version_removed)) {
      if ($version_removed[3] > ProjectCollector::getDrupalCoreMajorVersion() + 1) {
        $category = 'ignore';
      }
    }

We could add a filter option to the drush command to filter the ignore category.

🇭🇺Hungary Gábor Hojtsy Hungary

Putting the two above screenshots side by side.

🇭🇺Hungary Gábor Hojtsy Hungary

The planning component one is tricky I think because there is already a category called plan which is global to projects and I think people are used to using it. I added the rest but there may be some interesting dynamics between categories and components. Eg. "Feature request" category vs. "ideas" component or "Support request" category vs. "Feedback" component. We'll see. I think this is good enough?

🇭🇺Hungary Gábor Hojtsy Hungary

Duh probably I created the MR wrong then. Either way, committed that one line directly, that was easiest, instead of trying to fix the MR. Thanks!

🇭🇺Hungary Gábor Hojtsy Hungary

Good find! One line fix makes total sense.

MR had merge conflicts :/ I tried to create another branch to make this easier but that does not want to update from the original repo either without local merge resolution. Strange. Can you help with resolving that or should I directly commit to 7.2.x (with proper attribution of course)?

🇭🇺Hungary Gábor Hojtsy Hungary

Drupal CMS and recipes seems like a good fit for anti-spam/anti-abuse modules where there are big benefits to being able to swap in and out (and combine) different approaches. It would not take 16 years to move something in or out of starshot as it has here.

Fully agreed with this. Updated the suggested version numbers in the issue summary to reality. While the core committers did not agree yet in 2023 on this, I think the project browser + recipes solution changes the situation significantly for modules like this.

🇭🇺Hungary Gábor Hojtsy Hungary

I committed https://git.drupalcode.org/project/deprecation_status/-/commit/ea070840e... to run automated tests on Drupal 11. That has an automated info file fixer:

$ grep -q "\^11" *.info.yml || (grep -q "\^10" *.info.yml && sed -i "s/\^10/\^10 \|\| ^11/" *.info.yml)

and it passes Drupal 11 with that. While the tests are only smoke tests, I think its fine to commit this and declare Drupal 11 readiness for good.

🇭🇺Hungary Gábor Hojtsy Hungary

I am a core product manager.

I agree with deprecating Drupal 6 and 7 migrations to modern Drupal in Drupal 11 and removing the code for these in Drupal 12 without replacement / contrib placement given the age of the code. I think if someone really needs it (eg. folks that work on extending Drupal 7 support one way or another would still need it in 2028), they can do it. But I agree we don't need to officially mandate or support a contrib solution for this. Removing the review tag.

BTW I also agree that whether migrate's destination plugins and APIs should also remain in core is a separate issue that also needs to be discussed. My feeling is that without the Drupal 6/7 use case, it will be far from an 80% module. It is also not in danger of having competing solutions in contrib (eg. more similar to webform than to layout builder / paragraphs / Gutenberg), so I don't see dangers of moving migrate's APIs and module too into contrib, but once again, I agree that would be its own issue.

🇭🇺Hungary Gábor Hojtsy Hungary

I don't think it is needed for MVP, but added as a post-MVP. I think for MVP we can hardcode lists of recipes for the Site and Site feature level both, if recipe classification is not there yet. But we can't install recipes without PB supporting it, so that is the primary focus :)

🇭🇺Hungary Gábor Hojtsy Hungary

@mandclu directed me here. I did not even know "Site" type recipes exist, but they appear like only a docs concept. I think eventually Project Browser needs to differentiate between the "Site starter" and "Site feature" level recipes and not necessarily offer the basic component recipes that are there for reuse, so these classifications would need to show up somewhere on the recipe structure level. This is not necessarily a requirement I think for Starshot, since Starshot's early versions can hardcode lists of recipes in these categories in their project browser source plugins I think, but ultimately this will be needed.

🇭🇺Hungary Gábor Hojtsy Hungary

Yes I think it can use that. I don't personally have enough experience with the existing dashboard solutions for Drupal to say specifically :) I think this can be prototyped in the prototype with PRs though :) I am not sure about inviting to delete later, but parts of it should become less relevant indeed. Not sure how to handle that yet, but in the early stage you would be more interested in extending the site, while later you would value stability and not installing random stuff :)

🇭🇺Hungary Gábor Hojtsy Hungary

I believe this is something we will definitely want in Starshot. This was the only screen from the mockups that Dries showed in the Driesnote. I don't know what else to do with this issue :)

I think there is an MVP goal of having hardcoded CMS recipes and hardcoded additional recipes separate which is what Dries stated .

For a non-MVP I think there is an underlying task between recipes and project browser to identify the "CMS" level recipes from the "additional" recipes. And a stretch goal of somehow having a mapping of which additional recipes are suggested on top of which CMS recipes at least as "most suggested" or somesuch.

🇭🇺Hungary Gábor Hojtsy Hungary

Retitled for that then. I think we can keep one issue here and one with the project browser? But the implementation would be in project browser IMHO.

🇭🇺Hungary Gábor Hojtsy Hungary

Did I understand this right that this would be about the dashboard frame of the page basically, and is different from the META that way? That's what I retitled it with.

🇭🇺Hungary Gábor Hojtsy Hungary

Added words that I was missing from the title to make it clearer why you opened it. Feel free to fix it as needed.

🇭🇺Hungary Gábor Hojtsy Hungary

I think shipping with Olivero responsive image config is a good idea if we are shipping with Olivero. Why don't we think core should ship with those? Core already ships with Olivero specific blocks for example.

🇭🇺Hungary Gábor Hojtsy Hungary

Starshot ideally would not ship code on its own like this but it would be in a module. Is such a module available? Can there be one? People should not be waiting on Starshot to implement such features IMHO, this is entirely possible to do in a contributed project I think. So I think issues in the Starshot queue would be about including/integrating this solution in Starshot.

🇭🇺Hungary Gábor Hojtsy Hungary

Gábor Hojtsy changed the visibility of the branch 3448521-remove-inactive-initiatives to hidden.

🇭🇺Hungary Gábor Hojtsy Hungary

The FAQ has been further extended. Starshot is now included on the initiatives page and has its own project page now. We'll update these as we know more. I think we can consider this fixed to the extent we know currently.

🇭🇺Hungary Gábor Hojtsy Hungary

From the Easy out of the Box tasks, Claro has been done and included in core as stable. The Layout builder parts were superseded by the Experience Builder Initiative and the Media parts I think are superceded by the Starshot Initiative.

🇭🇺Hungary Gábor Hojtsy Hungary

I don't understand how "block plugin" related to the topic of this issue. Also I think #12 is the screen that would be provided by Project Browser and I thought based on the title that was meant to be covered by this issue. For #20 I think first a dashboard like thing should be available in Starshot, then project browser can expose a block for that dashboard. I think the #12 and #20 screens are quite separate, and in total at least 3 or 4 issues.

1. Project browser should have a "mini" screen that can be plugged into the end of the installer.
2. Either project browser itself should plug it into the end of the installer or Starshot should inject it there. I think PB would be a fine place.
3. Starshot should have an admin dashboard.
4. PB should have a dashboard block to offer additional things to install.

I think (1) and (2) of these are MVP, not sure if (3) and (4) are.

🇭🇺Hungary Gábor Hojtsy Hungary

The navigation module snuck in the 2020 logo actually, so I think this is somewhat resolved. However, it was just redesigned slightly, so needs a change again :D 📌 Update the Drupal logo in Drupal core with the 2024 brand evolution Active .

Production build 0.69.0 2024