🇦🇹Austria @arthur_lorenz

Created https://www.drupal.org/project/lupus_decoupled_news → and released version 1.0.0

Great, thank you :)

Tested it locally -> RTBC ✅

jjchinquist → credited arthur_lorenz → .

Test failed, cache is not being invalidated after config changes.

To reproduce:

• Install lupus_decoupled_site_info module
• Go to /api/site-info -> Info is correct
• Go to /admin/config/system/site-information and update the slogan
• Go to /api/site-info -> Info is outdated

Let's close this!

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

Created recipe: https://www.drupal.org/project/lupus_decoupled_blog →

arthur_lorenz → created an issue. See original summary → .

arthur_lorenz → created an issue.

PR got merged!

fixed and merged!

arthur_lorenz → created an issue.

👋

To summarize: The latest updates added a test of the login form provided at /ce-api/user/login by extracting the form build id and building the post request against /ce-api/user/login again. That's a sane way to test the provided form.

Code looks good to me and builds are green -> RTBC

jjchinquist → credited arthur_lorenz → .

Thx, I updated and commented the PR.

First, here are the Links to test the gitpod environments:
Base
Demo
Blog

Let's move the discussion for different project types here:
I introduced the env variable LD_PROJECT_TYPE that lets you choose between predefined sets of environment variables, for the ideal configurtion depending on the use case. Since we agreed on using this repo as project template as well as a demo, I figured this would be a clear way to differentiate the different types.

E.g. for demo purposes it makes a lot of sense to use the better styled shadcn frontend repo rather than our empty nuxt3 demo repo. All of the used variable can be overridden, so we don't lose any flexibility. It will make the transition to github code spaces also easier, since we do not have to keep various variable combinations in mind. And in case we want to streamline the installation process for local environments aswell, this will be a good starting point.

thx, merged PR

Draft PR on GitHub

PR on GitHub

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

PR on github

arthur_lorenz → created an issue.

Hey :)

To create a podcast episode you'll need to either go to "/podcast-episode/add" or navigate via Admin UI to Podcasts > {{ Podcast }} > Episode List and click on "Add Podcast Episode". When published it will automatically be listed in your podcast feed.

The content type podcast episode page is just there to display an episode on your site. By default it's a simple node with a reference field for your podcast episode. You can adjust to the fields and form/view displays like for any node type at "/admin/structure/types/manage/podcast_episode_page"

I hope this helps

I had another look at this.

is that data- attribute not handed over to the frontend?

The antibot key is not part of the data-attribute, it is put in the drupalSettings object only.

I agree we should move the code current code lupus_decoupled_antibot and come up with a proper solution for FE. However, the main reason we wanted to support this was that it was part of Drupal CMS. Shortly before the release of 1.0.0 it got (temporarily?) thrown out due to a11y issues 📌 Remove Antibot module because of unaddressed accessibility issues Active

Since there is no timeplan yet to re-add it to Drupal CMS I'll postpone this ticket.

No.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

Great idea!

Let's have a brain storming session on how we want to implement it and what your exact requirements are!

klausi → credited arthur_lorenz → .

Added some simple documentation. Follow up tickets will come later.

arthur_lorenz → created an issue.

Thx, I removed the first condition.

leymannx → credited arthur_lorenz → .

It's imo safe to ignore those issues, see comment in MR

arthur_lorenz → created an issue.

On Drupal side i think it's enough to expose the antibot key as a form attribute. The transformation of the key must be handled by the frontend.

arthur_lorenz → created an issue.

arthur_lorenz → created an issue.

It's simply the frontend that has no background color specified and is therefore transparent. Nothing to change here!

Thx, comments were adressed. I tested by creating a webform including 2 pages and confirmation page -> works like documented.

By default webform uses the confirmation type "page". However confirmation pages are not supported, resulting in a redirect to Drupal's frontend. I see multiple possible solutions:

• Support confirmation pages
• Disallow confirmation types except for inline confirmation
• Set inline confirmation as a default and add a warning if changed to any non-supported type

Thanks, updated the deprecation message and added a test.

Adressed @smustgrave's comments.

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

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