🇦🇹Austria @arthur_lorenz

breidert → credited arthur_lorenz → .

jjchinquist → credited arthur_lorenz → .

Merged

Also fixed CS and phpunit issues. Merged

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

jjchinquist → credited arthur_lorenz → .

It was a blast :)

Tested on D11 and merged.

merged and done

merged and done

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

It was a blast, big thanks to the organizers and speakers!

merged and done

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

Commented and added tests for altered paths.

Fixed and merged.

Thank you! ['/ce-api?param=1', '', TRUE] actually failed. Fixed it and added a couple of test cases.

Added a simple unit test to check if base paths are considered.

The resulting pipeline does still not pass.

I can not confirm this. The pipeline is passing

Otherwise you are right, this should rather be handled and documented in a separate issue 🐛 Respect installations with base paths Needs review .

arthur_lorenz → created an issue.

Argh, that didn't make any sense. The fields i was accessing were generated by a magic getter.

Ah sry this error comes from another MR

arthur_lorenz → created an issue.

Thx, good catch, I improved the string replacement.

No, that's not the merge request. This is: https://git.drupalcode.org/project/viewsreference/-/merge_requests/38

P.S. I applied this patch.

You should've applied the patch from the referenced merge request :)

I assume the issue is similar to this: https://www.drupal.org/project/lupus_decoupled/issues/3395669 📌 Make the gitlab-ci pipeline pass Needs review

We need to make the middleware consider possible path prefixes!

I fixed the middleware to work with path prefixes.

arthur_lorenz → created an issue.

After some debugging I'm confident that I have located the issue: The BackendApiRequest middleware is checking for the /ce-api prefix in the server's REQUEST_URI. Since the base url in gitlab ci is http://localhost/web, the actual uri that is checked at that point is /web/ce-api/node/1 which the middleware does not recognize as a valid ce api request and therefore passes the request through without altering it.

I did not have time fix it yet though.

arthur_lorenz → made their first commit to this issue’s fork.

Fantastic :)

For me still doesn't work. When enabled MR38 it works as before, when i submit the field edit form, only argument and pager can be enabled in Enable extra settings.

In the config export i see this:

enabled_settings:
argument: argument
limit: 0
pager: pager
offset: 0

Hmm, looks like the schema did not get updated. Did you clear the cache?

If i change to

enabled_settings:
argument: argument
limit: 1
pager: pager
offset: 1

and import the new config nothing happens, i don't see the limit and offset options in the entity where the field is included.

Of course, the value should match the key, as for argument and pager. So you'll need to change it to

  enabled_settings:
    argument: argument
    limit: limit
    pager: pager
    offset: offset

The config schema for the field settings was off and expected integer values instead of strings. The config is saved using the option value instead of some integer/boolean, e.g.:

enabled_settings:
    offset: 'offset'
    limit: 'limit'

arthur_lorenz → made their first commit to this issue’s fork.

but I'm kind-of weirded out by the notion that anonymous/authenticated roles would not exist

In the end both roles are just some config. If the config was not yet applied, the roles won't exist. But I should add the user module as dependency.

and a little afraid that now they won't get the "restful get rest_menu_item" permission assigned as they should.

don't be :) Usually this should only occur during site install with existing config. Then the permission should be applied in the config files and imported later on. Otherwise the roles should already exist. If not there might be a reason for it and it should not fail.

But I'm wondering if it makes more sense to check the `$is_syncing` and skip the step if it's true to not mess with any config.

arthur_lorenz → created an issue.

Thank you, testing previews on a fresh D10.1 with our nuxt kickstarter frontend was successful.

Tested:

• Preview Button in node form
• Responsive Preview modal in node form
• Responsive Preview modal in layout form

I found a couple of small issues in the MR

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

That's a valid point the amount of menu items might easily get out of hand. I'm thinking of moving it to a submodule to use at one's own risk since most use cases might cover a handful of podcasts max.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

How to reproduce on a fresh D10 install:

$options = [
  'query' => [
    'uri' => 'foo/bar',
    'page' => '/test',
  ],
];
$url = new \Drupal\Core\Url('<front>', [], $options);
(string) \Drupal::service('link_generator')->generate('Example link', $url)

will result in

<a href="/?uri=foo/bar&amp;page=/test">Example link</a>

Thx, cleaned up the code and fixed cs issues.

I added a new config to enable/disable a check if the selected log group or stream is valid.

Added the new config to the schema.

I extended patch #5 enable the users to create their own message format providing more metadata.

This patch only works well on simple fields like text fields. On more complex fields, e.g. entity_reference_revisions, you are not able to translate the referenced entity and its fields.

argh, sry for spamming, the last file contained a line that should not've been there.

There was a leftover statement in the function docs - removed it.

The problem: The layout builder loads the blocks by the referenced block revision id, that is saved in the layout field. As soon as we add a translation to the block, a new revision is created, becomes the default revision and the one referenced in the layout field becomes outdated. If we now update the block in the original language it creates a new revision that is based on the outdated revision and therefore has no effect on the translations.

Solution: Update the referenced revision in the layout when a translation is created or updated. Also update all nodes that have translations so all block translations are in sync again. This will cause the original language to be set back to the point where the revision got outdated (because the translation was created). My solution to this so far is to create a new node revision in the update hook to be able to revisit the latest version of the block. But the content has to be updated manually.

Thx improved naming and code docs.

It's not a Drupal local-task, what could be confusing if the API returns it as local task then.

True. But imo from a user's point of view it is much nicer to have this in the local tasks then rendering an additional link in spot that is only used for this exact link. This link would also need to be taken care of in the frontend to be sure it's styled etc. To me it's equivalent to the Edit link in core's local tasks, that's why I want to have it there.

Then, it's not nice to special case code of individual routes in there.

Well, the node module basically does the same in a hook_page_top. Just the outcome is worse imo.

Drupal has APIs for adding local tasks for routes, so if anything we should use them. But that might show up when not using drupal-ce as well.

Exactly, we don't want to interfere with the core functionality here. My goal is to avoid overcomplicating the task. I think the question is whether we want to map Drupal's functionality 1:1, or if we use the gathered flexibility of our custom renderer to add tiny UX improvements like this without having to create a core issue or similar. But the more I think about it I come to the conclusion, that this module might not the right place for this change. Let's discuss it in the next weekly

Thx, updated MR and additionally uploaded a patch file.

Thx, MR looks good!

Thx, fixed the CS issues here.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

MR !34 enables the frontend redirect for node preview and revision routes.

arthur_lorenz → made their first commit to this issue’s fork.

Tested on a fresh ddev installation. Works as expected!

fago → credited arthur_lorenz → .

Yes, you are right, I did not find the time yet to properly document the module. You'll need to have the Geolite 2 city database file in web/libraries/geolite2/GeoLite2-City.mmdb

You can either download and manually place it there, or add the following repository to your composer.json and run composer require podcast-publisher-analytics/geolite2

        {
            "type": "package",
            "package": {
                "name": "podcast-publisher-analytics/geolite2",
                "version": "1.0.0",
                "type": "drupal-library",
                "dist": {
                    "url": "https://cdn.jsdelivr.net/npm/geolite2-city@latest/GeoLite2-City.mmdb.gz",
                    "type": "gzip"
                }
            }
        }

On install the service provider is called before config is added to DB -> added a fallback

arthur_lorenz → made their first commit to this issue’s fork.

fago → credited arthur_lorenz → .

fago → credited arthur_lorenz → .