Over the last day, I have been going round in circles trying to get Collections working in my DevPack. I couldn’t get the Collection setup to work and so I loaded the RealMac acme.table DevPack from Github and installed the component in my DevPack.
I then went through line by line checking mine against acme.table. Corrected a few issues and still the modified acme.table worked in my DevPack but my Collection didn’t. I was seeing property updates that I did in Nova not being reflected in Elements. The only way I could eventually get them to take was to save my Elements project and restart Elements.
Maybe there needs to be a “force reload” button in the Elements UI, to get the reload the latest copy of a DevPack under development?
I then experienced a separate problem where I did a re-publish all files but the website wouldn’t load as it said the RW subdirectory in the backend directory was missing; it was. This was even though Elements had provided the backend path to me (as evidence by a debug error_log message). Again, I quit Elements, restarted Elements and did a re-publish and the backend folder was magically re-instated!
However, now the acme.table collection isn’t finding any rows, even though they exist in the properties and I can add rows. They aren’t shown in the Elements Editor which seems to imply there is a disconnect somewhere?
So I have got two separate collections in the same component (mine and modified acme.table), with mine currently working. It seems to me that this area is a little bit flaky as making changes to the Collections in Nova doesn’t always get reflected in Elements, or so it seems? I am not convinced that my collection isn’t going to disappear again with no entries shown and the modified acme.table re-appear?
Anyway, a bit of a ramble but thought I would flag it up!
It sounds like you might be using the same identifier for both collections, which will certainly cause issues… hard to tell without doing a deep dive on your component!
There is definitely an issue with how Elements is publishing (or not as the case may be). I updated a PHP file in shared/assets and when I published the site, it wasn’t updated.
So I did a publish all and that didn’t update it. I then quit Elements and then restarted Elements and did a Publish All (having deleted all the files on the published site) and then it was updated. However, that process caused another issue as not all the backend RW folders were created with their content.
From my PHP log (edited):
[28-Mar-2025 18:42:12 UTC] $backend_path: ./backend/rw6BBC91D5_50AA_44A1_AED3_2FE25FF7EF79/
[28-Mar-2025 18:42:12 UTC] $site_asset_path: ../rw/elements
...
[28-Mar-2025 18:42:12 UTC] PHP Warning: require_once(./backend/rw6BBC91D5_50AA_44A1_AED3_2FE25FF7EF79/Parsedown.php): Failed to open stream: No such file or directory
PHP is correct, it isn’t there. I would expect three of these type of sub-folders to be present but only one is.
At the moment, quitting Elements, restarting and republishing isn’t resolving the issue.
It’s hard to say without seeing more, but I can give you some pointers. I’m guessing you know the following so just for clarity,
All paths in Elements are relative to the page
A path starting with / means the root of the file system
A path starting with ./ means the current directory
A path starting with ../ means the parent directory
The siteAssetPath is relative to where the page is running, either at the root of the site if it’s the home page or within a subdirectory. However, backend php files are nested two levels deeper than the page, backend/[node id]/file.php. So to use the siteAssetPath in a backend php file, you should prefix it with ../../ like this:
After digging into this a bit more, it turns out the solution is to explicitly specify a folder for the page. Out of curiosity, was there a particular reason you wanted view-post.php at the top level?
Publishing multiple pages to the same folder can easily lead to file conflicts or other unexpected behavior, so it’s generally best to keep things separated.
Hi Tom, No not specifically but I was trying to test all options as I do not know what users are going to do when the build a website using the Components I am building; especially as Elements allows you to do it.
So presumably if you are at the root level and specify index.php as the page you are OK, it is just if you add additional php files. like anyname.php?
So I guess, either this needs to be fixed or Elements should prevent you from having additional files at the root level (not sure that is a good idea?).
Yes I think this is the fix, we need better validation on the folder name. We could allow other files at the top level via some other UI if it’s necessary, like a robots.txt file. However, I think pages should always be in a folder.
:
