🇭🇺Hungary @Gábor Hojtsy

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

Ok this now makes phpstan and cspell happy and makes a dent in phpcs :) Good enough for me.

gábor hojtsy → created an issue.

2.0.x now passes gitlab :)

That works beautifully, thanks!

@godotislate: I don't believe that is a problem, we are testing whether on form submission the entity gets the language, and it appears it does not (likely the third party setting is not saved).

Can you put this into an MR? That way tests would run on it too :)

The remaining fails are around #edit-seo-settings #edit-metatags-0-basic-title of course. I still did not find where this one comes from metatag, but access false-ing the parent does make this inaccessible apparently.

Would be good to get a clear answer from the XB team whether the field should stay and further altering should be put into place (as in #13 but that does not list all the items, see #14) or the field should be removed (which does sound like would be the cleaner solution IMHO).

I understand that @damienmckenna. I don't have an opinion either way, so I personally leave considering that to @lauriii and/or other code owners in this area of XB :) My main aim is to make metatag and XB work peacefully together, I don't have architectural opinions about this, trying to help with whatever is needed :)

gábor hojtsy → created an issue.

Very complete suggestion, thanks! From my visual review, it looks fine, however I don't use config split :) Can you get anyone else review / try it? It looks like it would not have negative side effects at least, but would be good to have another set of eyes/hands on it.

Due to a mismatch in when I checked the credit, the commit credit did not land with @penyaskito and @diegors unfortunately, sorry. The issue credit was properly set though.

gábor hojtsy → created an issue.

I'm not interested, but it is open source of course, so you can create other versions yourself.

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

Most of the calls changed are in static methods, those don't have a $this. Did you actually try if the change worked? Screenshot of it applying cleanly does not prove it works.

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

None of the fruits seemed low enough so released this with one other commit I already had :D https://www.drupal.org/project/upgrade_status/releases/4.3.8 → Thanks again!

Thanks all! I get the irony! :) Hope this helps. Will do a release too later today, but will check first if there are other low hanging fruits to include too.

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

gábor hojtsy → changed the visibility of the branch 3531991-experience-builder-has to hidden.

Had a zoom meeting with Lauri where I showed him the current state. XB has an opinion on what basic SEO fields should be shown and implements all of them as base fields (except the SEO title). So the metatag field is mostly used to wire in the token replacements as shown above in #17. I understand this could be in global config for this entity type. Lauri told me that keeping the field would still be better as it would give the option to create a custom, simpler widget for more complicated SEO settings in the future. I think the field could still be added then, but my aim is to solve metatags not working with XB, not to argue about architecture :)

So attaching a few lines of added code that alters out the metatag section of the form at the existing place where it moves the SEO title field. This works for me, although I don't have the SEO title field somehow in metatag 2.1.1 that I have, so not sure if that would be affected by the #access even though it is moved out of the group. I think for this stop-gap issue that is the remaining question.

Fails are unrelated to this MR, so moving to Needs review. I think it fulfills what it was meant to do. Webform maintainer decision is needed as to whether the block dropdown makes sense compared to the autocomplete. I think its a better user experience, but could indeed get unwieldy if someone has a loooooooot of forms.

Let's keep the scope of showing up as dynamic component which is already achieved :)

Updated issue summary with current problem list and made title more generic given that we have shifted the scope a bit in this issue already :D

Roy is a legend! Your move away to other life things is very much understandable but you gave so much to Drupal. I will forever remember the drawing meetings where you turned your camera on your piece of paper are we conceptualised things on the spot.

https://www.drupal.org/project/puwg → was launched in the meantime indeed, so I agree this can be closed as won't fix.

https://github.com/mdlutz24/drupal-meeting-parser is the chrome extension to save the slack meetings nicely. If there are any bugs, happy to help commit fixes as one of the maintainers :)

Note that DrupalCon itself provides per speaker social share images, I'll let them know of this issue and try to figure out where that is at, if done already or not, etc. Those could also be used :) I don't think those are the only ones to use exclusively but they will help.

Also there are more AI sessions than listed and also a workshop :) Maybe a decision flow graph kind of thing could also be useful like the one I created back in the day for the contribution events. This one :D

chrisfromredfin → credited gábor hojtsy → .

Also Adam Hoenich may know if it was intended that the recipe name was not pulled dynamically but rather an alternate name was possible to be provided here. That may be a loss of a feature to not allow that anymore. That said it would be harder to translate it then :D

Is this an API that is being changed or is not? Looks like it is defined by recipe_installer_kit :)

Is this issue for discussion? I think the ultimate MRs will be against recipe_installer_kit and drupal_cms repos?

xjm → credited gábor hojtsy → .

xjm → credited gábor hojtsy → .

I agree with @longwave's summary from #15, removing the product tag as a Drupal core product manager.

New MR needs to be merged to avoid the (not different!) whitescreen that my previous one introduced.

Expanding the scope a bit, since this could be about the initial working version of it which seems to not be too far off.

Fixing the demo design system bug at 🐛 Webform handling has implicit dependency on paragraphs, whitescreens Active to make the webform show up at least :)

gábor hojtsy → created an issue.

@damienmckenna: are these mappings possible to reproduce in a global config somehow? I think the reason for the field is to use these mappings for xb metadata (unless explicit settings otherwise).

          ->setDefaultValue(Json::encode([
            'title' => '[xb_page:title] | [site:name]',
            'description' => '[xb_page:description]',
            'canonical_url' => '[xb_page:url]',
            // @see https://stackoverflow.com/a/19274942
            'image_src' => '[xb_page:image:entity:field_media_image:entity:url]',
          ]))

Woah I figured out that the error in layout was due to the demo design system attempting to use Paragraphs even if its not even installed on the site ONLY if there was a webform :D

It does render now! BUT the selected webform value still does not persist.

@gxleano suggested to change the widget to a dropdown instead of an autocomplete. That behaves the same. I can even save it but then it says the tree is broken (and even the undo in the dialog does not work).

When locale is enabled, does the remote translation checking / downloading happen automatically too? I fully agree that this message in the installer is distracting, superfluous and should be removed. It is unfortunate if that also means that there is no guidance once the module is enabled where to take the next step, unless it is already taken for you. This is a problem for other modules as well, so this was/is a one-off solution I think after all but unless it happens automatically as well, I think we are leaving users in the middle of nowhere with this.

Can we somehow add back the feedback when an individual user action (eg. running translation updates or importing .po file) is done? I think with this MR if you do a manual action that affects your translations, you may not be getting any feedback?

I do agree the same feedback in the installer is useless, superfluous and distracting :)

Adding related issue in 🐛 Autosave publish process does not acknowledge pathauto deactivation Postponed that may cause the checkbox to not work. Even if that would work I think "metatag" working fine is not quite leaving every single field as-is in the sidebar, so lacking further product direction I think leaving all but the XB base field provided (image / description) SEO stuff out for now would be much better. Otherwise (even if the checkboxes then work fine) enabling metatag throws this massive amount of form elements, most of which are quite confusing and super advanced.

That said, until the checkboxes get fixed we do need a workaround that keeps metatag working IMHO.

@mglaman: with that alter the basic elements go away as expected, the closeable metatags section becomes a non-closeable Advanced but the robots checkboxes are still there and therefore lead to the error described. Is that the full extent of the alter you use? All these fields are still present with that alter hook from #13 which I doubt you all expose to users @mglaman :) I'm using metatag 2.1.1.

Let me repeat the key question: Does metatag need the field to be present to pull from the description and image base fields for metadata?

This is with sidebar FALSE :)

@catch: I think its also fine to do something along these lines in XB. As said this is a stop-gap.

@damienmckenna: XB adds the metatags field as a base field, and it is set as internal but also configurable :D I don't think there is a way to actually configure this, it does not show up on admin/reports/fields and also XB does not have a way to edit the fields on XB entities (by design I think).

Does metatag need the field to be present to pull from the base fields for metadata? The only thing that XB pulls out of this for its own SEO settings is $form['metatags']['widget'][0]['basic']['title'].

I think "out of the advanced section" in code terms if sidebar FALSE? When I tried that it merely made the metatag fields show up above the SEO settings section. Same problem with robots field then though :)

  #[Hook('entity_base_field_info')]
  public function entityBaseFieldInfo(EntityTypeInterface $entity_type): array {
    $fields = [];
    if ($entity_type->id() === Page::ENTITY_TYPE_ID) {
      if ($this->moduleHandler->moduleExists('metatag')) {
        $fields['metatags'] = BaseFieldDefinition::create('metatag')
          ->setLabel(new TranslatableMarkup('Metatags'))
          ->setDescription(new TranslatableMarkup('The meta tags for the entity.'))
          ->setTranslatable(\TRUE)
          ->setDisplayOptions('form', [
            'type' => 'metatag_firehose',
            'settings' => ['sidebar' => \TRUE, 'use_details' => \TRUE],
          ])
          ->setDisplayConfigurable('form', \TRUE)
          ->setDefaultValue(Json::encode([
            'title' => '[xb_page:title] | [site:name]',
            'description' => '[xb_page:description]',
            'canonical_url' => '[xb_page:url]',
            // @see https://stackoverflow.com/a/19274942
            'image_src' => '[xb_page:image:entity:field_media_image:entity:url]',
          ]))
          ->setInternal(\TRUE)
          ->setProvider('metatag');
      }
    }
    return $fields;
  }

Does XB really need the metatags field on the entity for metatag to work? The easiest would be to not even have the field on :)

BTW did not include in the video, but when trying to save the page, there is an error with the "Contact" machine name. So looks like the title is not translated to the machine name with the autocomplete. Why would that be a problem?

Added 📌 Experience builder has limited built-in metatag features, disable advanced form fields there as initial stop-gap Active as metatag must have, given basic metatag works with it already, but breaks without it.

Added more info on which bits are metatag code in XB.

Added screenshot.

gábor hojtsy → created an issue.

The startup experience on new sites just came up again in the Slack channel. Is there a concept for how would people create their first XB page and/or enter XB without knowing about an existing XB page and going to the edit page of that? Or what happens when/if they delete all their XB pages (such as deleting demo content), how can they get back to XB?

For pconfig, you linked a human created copy of the automated issue. The automated issue is at https://www.drupal.org/project/l10n_pconfig/issues/3431526 📌 Automated Drupal 11 compatibility fixes for l10n_pconfig Needs review and it looks like it only found the info file to fix :D That could very well be the case as I don't think much changed between the language forms in Drupal 10 and 11. I think that would be easy to land if someone manually tests it.

Is there a list of tags that is proposed to be changed?

@wimleers: video attached. Only schema fixes are applied are 📌 Make webform blocks (block.webform.block:*) fully validatable so they can be used in Experience Builder Active from the current MR.

@wimleers: the webform block is a generic block. You configure it by setting the webform name in the autocomplete (where the screenshot says "Contact"). Unfortunately while this autocomplete itself works in XB, the data is not stored. If you click away to a different component, click back, it does not persist. Also, the block is not rendered with the webform name picked, so you still have a component that you can only pick out from the layers tab.

I'll try to create a gif or video but while updating to xb 0.4.0, somehow the webform schema fixes do not seem to apply.

xjm → credited gábor hojtsy → .

Did not land in 11.2, so updated the CR draft to say 11.3. Also tagging for release highlights for 11.3.

xjm → credited gábor hojtsy → .

gábor hojtsy → created an issue.

Thanks all, merged finally :)

Yay, thanks!

Also did not get into 11.2.

Does XB have a way to alter this message? If not, then this issue may need to be postponed on an XB API to be created for this :) Or XB would need to pick up the message from some generic source that Trash altered :)

Once again, I did not disagree with whatever the date is, I was commenting on what it means and how it will be interpreted. We don't need to agree on that part though, so that should not hold up this issue at all.

I agree with @berdir and @penyaskito this does not actually create a translation, it is probably best to live in contrib.

Yes, it could be Drush commands or a contrib module. With Experience Builder taking on a lot of the admin UI, it will be more and more odd to try to have a separate different admin theme unless it blends in with Experience Builder (which is not quite theme-able as such).

griffynh → credited gábor hojtsy → .

pameeela → credited gábor hojtsy → .

pameeela → credited gábor hojtsy → .

pameeela → credited gábor hojtsy → .

griffynh → credited gábor hojtsy → .

gábor hojtsy → created an issue.

Looks great IMHO, thanks a lot!

In the current MR there may be two .po files downloaded, the drupal core one and the install profile one.

Are both imported to memory for the installer?

If so, this would be overkill for packages like Drupal CMS that ships with core, so it would import two huge .po files?

However it would be needed for install profiles that customize the installer (eg. add steps to it) but use regular d.o packaging and thus do not bundle core and projects inside it.

Also, in the later stage of the installer, the installer downloads a lot more .po files for contrib projects (both in the core + install profile scenario and Drupal CMS). Is that also loaded into memory (not needed)? Or Does that confuse which .po files get loaded (that would be a problem). Also for the case of Drupal CMS if it includes all the core and contrib projects it ships with in terms of translations, and it already has that one .po file, it should not download more .po files and import then as that is duplicate work and unnecessarily slows down the installer, no?

xjm → credited gábor hojtsy → .

Re #39, I don't think in terms of those two groups of people, I think people would look at the date and plan their timeline backwards rather than the other way around.

I think if we say EOL on December 9, 2026, then people would understand that they need to be off of it soon after to not risk an unfixed security problem. If EOL is December 16, then they need to be off of Drupal 10 by the third week of January to avoid a disclosed security problem.

There is a lot of explaining in this issue that either way its most likely December 9 means the same as if Drupal 10 would be supported until January 19 (right before the January security window), but the proposed text is this:

Drupal 10 will reach end of life on December 9, 2026, after Drupal 12 has been released. No new releases of Drupal 10 will be made after this date.

Unless I am misreading this, users of Drupal 10 will need to plan for a disclosed security issue potentially on December 16 with this message. (I am putting aside other institutional knowledge I have because most people reading will not have that information). If our plans are different, it would be reasonable to communicate that IMHO. We don't need to have that as a plan, but I'm advocating to communicate what the plan is, rather than have insider info that is different than what the public information is.

I don't have strong feelings of either date, but I think it is important to document the implications in a way where the internal and external understanding is in sync.

gábor hojtsy → created an issue.

I asked how do they obtain it not how they enable it :)

@cilefen: do they change the admin theme? Which is that admin theme? How do they obtain that different admin theme?

Minor cleanup.

Reformatted the table as various lists for easier scanning and so we can list more issues and notes without breaking everything :) I think I kept all the info and now represent it better hopefully.

I think an EOL date briefly before a security window looks potentially scary to people, especially with that security window towards the end of the year holidays. But this could very well be just a theory. I understand the past year's practice and internal priorities, but I expect that those are not apparent to most other readers.

Once again, this could very well be a theory that does not hold, I have no way to tell at this point. If the release managers think this is not a communication concern we need to deal with, then we don't.

I don't know what did I wrote that sounded like I don't trust the security team. I'm advocating for clear information.

If there were something serious and urgent, we would provide a Drupal 10 release for it regardless of what the windows were and what the D10 EOL date was. If there were something that wasn't serious, we would simply not use the December window for it.

So why is it a window earlier than the security window, but "trust the security team"? The way you explain it is exactly an EOL on the security window. There will either be a last release then or not and there will not be a last release later. So that is the EOL is what you are saying.

Why do we expect people to read between the lines and recall years of practice each personally instead of just stating what the plan is?