The "Assets/Files/" folders should be named avoiding using the page ID

[Pixrael]

Problem: As the page ID is currently used for the creation of the page folder, does not allow the pages to be imported correctly when they are Exported/Imported in the admin.

Example: Having a website in production generating new content constantly, and in my development copy I add some categories, pages and other content that includes images, logos, etc. When I upload the local folders to the server, and export/import that pages, the relationship between them is lost, because the exported IDs are already used in production on other pages and PW generates new IDs. Another consequence is that the contents of the local folders are mixed in the folders of the online pages that share that ID.

Solution: Would be to add a new internal parameter to each page based on some kind of uuid, which serves as a unalterable reference for naming and accessing the folder related to that page.

[wbmnfktr]

Even though I never ran into this issue, I'd support something like:

/assets/files/path/to/my/page/whatever-image.jpg

Which could be used in one or another way, even outside of ProcessWire.

[Pixrael]

@wbmnfktr That would be fine, but sometimes we can change the name of the page (ex. by SEO criteria) or change the location of the page, however if a universal identification of that page is maintained, there will be no problems with the maintenance or updating of the project. and furthermore, it would not be necessary to reproduce the design of the site's navigation structure in a folder tree.

[MarkE]

6 hours ago, Pixrael said:

if a universal identification of that page is maintained

I'm not sure how this would be implemented. "Universal" implies it would be independent of the environment, but if a new page (and associated files) is created in the dev env, how can you create a universal id that you know will be unique in the production environment (unless the dev environment has knowledge of the production environment which, in PW, it does not).

I came across this problem in developing ProcessDbMigrate. If you use that to migrate pages, rather than the standard export/import, then hopefully it will resolve the ids correctly. See https://metatunes.github.io/DbMigrate/help.html#field-types.

NB: If you do use my module, please take care to take backups of both environments before installation and before any migrations - it is still very much 'alpha'!

[LostKobrakai]

If content is created in both dev and prod concurrently and meant to be merged then you're essentially maintaining a distributed system. There's a lot of knowledge around on how to deal with them, but all that doesn't make it a simpler problem and not having conflicts (or resolving them automatically) remains to be a hard problem. That's why the migrations module I created ages ago used migrations to captured the intent for change instead of trying to merge observed changes after the fact – the latter either comes with a lot of caveats or is impossible.

The simplest solution for the specific problem discussed is the suggestion of @wbmnfktr. Use two separate systems for files created in dev and pushed to prod vs. the system for files created in prod, that way there cannot be conflicts in the first place.

[MarkE]

On 7/17/2022 at 3:19 AM, wbmnfktr said:

Even though I never ran into this issue, I'd support something like:

/assets/files/path/to/my/page/whatever-image.jpg

Which could be used in one or another way, even outside of ProcessWire.

This has attractions. But it would require PW to update the file path every time the page was moved or renamed -  there would be other complications too - e.g. including an image in a RTE field in another page would mean that the html would need to be updated when the host page is moved/renamed. It might be possible to test out the idea using hooks, but my guess is that it would cause more problems than it solves.

The method I use in DbMigrate is to do all the referencing in the generation of the migration using the path/name rather than the id and then using that to get the corrrect id for the files. For RTE fields, an id map is maintained

$idMapArray[$page->meta('origId')] = $page->id;

so that the html can be changed. This only needs to be done for a migration, not every time a page gets moved. So I think, on balance, my vote is to keep the id-based naming.