[UX] URL Path settings don't save when creating a new content type.

[serundeputy]

URL Path settings don't save when creating a new content type.
Steps to reproduce:

• Visit: /admin/structure/types/add
• Configure the URL Pattern vertical tab.
• Save the content type

Creating new content of the new type does not have the URL Pattern setting (because it was not saved) and the URL will be an internal path of node/{nid}.

Visiting /admin/config/search/path/patterns will confirm that no path pattern setting is saved.

This only happens when creating a new content type, for example if you go in to edit the same content type that you just created /admin/structure/types/manage/memow/configure and configure the URL Pattern vertical tab it saves just fine.

[jenlampton]

Moving that note here :)

When creating a new content type, the field for Default URL pattern should contain the value provided for 'Default URL pattern' on the path patterns page (or none, if left empty). In config, this is saved as node_pattern.

However, when the page for a new content type is saved, the value entered needs to be saved as node_TYPE_pattern. Instead, a new value is being added for `node__pattern', since the type was not known when the form was generated.

[klonos]

Relatively related...

I very recently (past couple of weeks) was building an invoicing backend on D7 where certain fields including the node title were required to be auto-generated (using tokens and values from other fields) but this could not be done because upon node save, the value of those fields (nid + serial) was not available. They were available only after the node was saved.

A really tricky issue to sort. I finally resorted in using Rules + custom php code in order to update the field values after the node was saved. I had to do a lot of research and look around in various forums before I made it work (this specific setup involved field collections, so the php code to get/set values was accordingly complex). Although getting things to work was rewarding (I am a Drupal/Backdrop nerd after all), let me tell you it was a really horrible DX trying to achieve what seemed a really simple task. Any newcomer would have easily given up since day 1.

Can we please have a generic solution to this issue here so that there's a hook or some sort of other means to make entity properties and field values available during save?

[klonos]

...I'm guessing how such a thing could work is that there would be an intermediate stage between saving things and displaying the results, where there is a check for empty/missing tokens/values. If empty tokens/values do exist, then we have a second round of some sort of background re-save where these things would actually have non-empty (not NULL?) values and the respective settings and/or field values get updated. Then the thing is displayed.

Does that make any sense at all?

[jenlampton]

Does that make any sense at all?

That does make sense, and that is basically how it works already (having multiple stages of saving) which is (I think) why it's so complicated. What the system needs to do is 1) collect all the stuff and then 2) save all the stuff.

If you try to save anything before stage 1 is complete, you fail, because all the stuff has not yet been collected. Add into that module weights, and a fallback to an alphabetical ordering if the module weights are equal, and things still sometimes don't work how you expect in stage 2... ** head explosion **

I would love to see a rethinking of this process for DX in Backdrop 2.x. Can you please open a new issue? :)

[jenlampton]

I just filed a PR that fixes the bug with saving URL patterns while creating a content type. Needs review :)

[quicksketch]

Needs review :)

And a test. :)

[jenlampton]

Now with tests!

[quicksketch]

Awesome! The new PR had a conflict with some other recent changes. The test looks great but itself had a fail in it. Adding a static cache clear inbetween tests solved the issue. New PR filed with the fix at backdrop/backdrop#1485.

[quicksketch]

Merged in backdrop/backdrop#1485 into 1.x and 1.4.x for 1.4.4 release.