Updating page title or alias does not get reflected inside the navigator

const {
    data: pageItems,
    isLoading: isPageItemsLoading,
    error: pageItemsError,
  } = useGetContentListQuery('xb_page');

in PageInfo.tsx file.

Here we are getting the pageItems from ApiContentControllers::list() , which returns content values from $this->entityTypeManager->getStorage('xb_page'); entity . But since these are not published yet the value shows the last saved title or Untitled Page incase of new page. Inorder to reflect the immediate changes in the title in navigation drop down, we need to call and generate similar pageItems from AutoSaveManager::getAllAutoSaveList() .
This is my POV . Any feedback or suggestions are appreciated!

#4 is accurate. I can see how the title should update in the top bar where the Draft indicator is present. But I don't think it makes sense for it to be updated in the list of pages.

@anjali rathod: I think @lauriii gave the answer you needed in #6? 😊

@wim leers Yes. Should I go ahead with the approach I shared in #4 ?

🏓 on the MR. @larowlan's review/suggested direction will also require an update to openapi.yml.

P.S.: why the term navigator? 😅 That doesn't appear anywhere in the codebase.

working on the js test

The page title should always reflect the autosave version of the page title.

The page title exists in 4 places -

1. The value in the page data form field
2. The title shown on the dropdown button in the top middle
3. The title shown in the list of pages when you click the navigator
4. The title shown in the list of autosaves in the review changes dropdown.

I think the CURRENT page title can only be updated from two places

• Changing the value in the form field
• Publish all changes in the rare situation that the page was renamed in another tab/by another user

Other pages' titles (shown in the navigator) can be updated in one place

• When publishing all changes

Furthermore and not mentioned thus far in this issue, the navigator also shows the pages' url alias.

So, my proposed solution

1. When user types in page title, in real time, purely on the client-side we update the value in the dropdown button. This is already in place in 0.x
2. When user types in page title (or any field in the form on the right) we update the preview by calling the server This is already in place in 0.x
3. When user types in page title, we invalidate the cache of the pages list (/xb/api/content/xb_page) in the navigator (using invalidateTags)
4. We also invalidate the cache of the pages list when user types in the URL alias,
5. We also invalidate the cache of the pages list when a user "publishes all"
6. On the server side, when fetching the list of pages, the page title and url alias of each page returned should be that of the autosave if there is one.

Then we must ensure that when the navigator is opened, if the cache has been invalidated, we re-fetch the list of pages.

I've done most of the refactor that I suggested in #20

The list of pages that is returned from /xb/api/content/xb_page was previously updated to include a key autoSaveTitle . Can the same be done to also return an autoSavePath?

@jessebaker by autoSavePath do you mean a path similar to /xb/xb_page/1/editor ?
Because the path key value pair returned from /xb/api/content/xb_page gives the path for the autosave entity.

I chatted with @jessebaker about this.

This is about updating the path in the navigation to match the alias field if it was changed by the user

I am working on this

updated title and summary for alias updates

This is working around the problem introduced in #3500052, identified at #3500052-27: Provide HTTP API for listing Page content entities that can be updated by the current user, then discussed by @lauriii, @mglaman and I, and which @mglaman wanted to see solved in #3503446: Define xb_path entity key for identifying entity path field. At minimum, this MR's work-around needs to point to #3503446: Define xb_path entity key for identifying entity path field. But the consequence is that this MR will have to do some cache context trickery.

But it'd be better still to just do that first, to avoid having to introduce another layer of work-arounds here. I'm fine with being pragmatic and landing this first.

Note that "alias" was not in scope until #24 — @lauriii's original title didn't match the issue summary. 😞

@wim leers re #26

But the consequence is that this MR will have to do some cache context trickery.

I don't actually need to calls base_path() so hopefully this issue won't have extra cache problems. see https://git.drupalcode.org/project/experience_builder/-/merge_requests/7...

also I added a todo to #3503446: Define xb_path entity key for identifying entity path field to figure out the 'path' key dynamically

Seems like this needs to be fixed by stable

Reviewing…

Great work on this one — this looks very close! 😄

I wanted to merge it, but I couldn't help but agreeding with @larowlan's feedback WRT #3501847: Send entity keys to the editor from the mount controller .🫣

Raised 2 additional code clarity concerns (nullability instead of empty string, and autoSaveTitle → autoSaveLabel, which makes more sense once Lee's feedback is addressed).

@wim leers @larowlan thanks for the reviews, will address

setting to Needs Review. I think I have addressed the feedback but the pipeline is failing because of 403 errors in UI and Composer jobs. I think it is related to cloudflare issues https://www.cloudflarestatus.com/incidents/gshczn1wxh74

Will try to re-run the job in a bit

LGTM, but the UI eslint CI job has been consistently failing. Probably a trivial change is needed :)

RTBC, but won't be mergeable until the UI eslint CI job is fixed.

Looks like @wim leers just set this back to Needs Work for the ES Lint fail which @jessebaker fixed, thanks!

Ok. all e2e tests passed beside media-library, reran and media-library just passed🎉

2 e2e tests but re-tested and those have now passed