next-drupal icon indicating copy to clipboard operation
next-drupal copied to clipboard

New nodes do not revalidate the new path alias

Open pookmish opened this issue 11 months ago • 4 comments

Package containing the bug

I’m not sure

Describe the bug

When pathauto is configured and a node is created, the revalidator plugin only attempts to invalidate the /node/## path. It does not revalidate the new path alias generated.

Expected behavior

Revalidation should be executed with the new path alias.

Steps to reproduce:

  1. Fresh install with standard profile using 2.0.0 module version
  2. configure a path alias pattern for something simple like [node:title]
  3. configure a simple next site and entity type revalidation, configured to revalidate the page's path.
  4. Enable debug mode
  5. create a new node
  6. review watchdog logs
  7. observe the debug log for the /node/# path, but not the new path alias pattern.

Additional context

Image

pookmish avatar Feb 25 '25 21:02 pookmish

@pookmish I'm not sure if this is a bug, but do you need to revalidate the URL alias when creating new content? Before the content is created, accessing the URL results in a 404 page. Once the content is created, it should appear at the URL without requiring revalidation.

ksk1kd avatar Feb 26 '25 17:02 ksk1kd

@pookmish I'm not sure if this is a bug, but do you need to revalidate the URL alias when creating new content? Before the content is created, accessing the URL results in a 404 page. Once the content is created, it should appear at the URL without requiring revalidation.

When using ISR (or even some type of fetch/data cacheing), the page would cache as 404. It requires some type of revalidation to allow the page to fetch data. How would it just "appear" without being triggered for revalidating?

Yes if the path has never been access, no cache would be established for that path and it would build at request time.

My current work around on the NextJS side is to detect the /node/# revalidation parameter, then do a query against the Drupal site to find the newly created node, and revalidate the path to flush out the 404 page.

pookmish avatar Feb 26 '25 17:02 pookmish

You're right, I was able to confirm that the 404 page is cached in the Pages Router Starter. In the App Router Starter, however, it doesn’t seem to be cached, which is likely why no issues are occurring.

It looks like changing the following code to $event->getEntity()->toUrl()->toString() would allow the URL alias generated by Pathauto to be revalidated when a new node is created. That said, I’m not sure if this is the best approach. https://github.com/chapter-three/next-drupal/blob/next-drupal%402.0.0/modules/next/src/Plugin/Next/Revalidator/Path.php#L76

ksk1kd avatar Feb 27 '25 15:02 ksk1kd

@ksk1kd I tested out a version of your idea. If I change the EntityActionEvent to use the URL object instead of a string, it seems to invalidate the path alias as expected. I believe this gives the system time to register the path alias before the revalidation plugin is executed.

I'll put together a PR here: https://github.com/chapter-three/next-drupal/pull/844

Let me know your thoughts.

pookmish avatar Feb 27 '25 18:02 pookmish