I have still got the issue with Elements 1.1.1 (23782) where if in the Nova editor I change and save a PHP file in my DevPack Component that is in the DevPack shared > assets folder, when I republish the project that includes this DevPack, that file isn’t being published. This is even with a Publish All Files.
To get it to publish, I have to quit Elements, re-load the project and then do a Publish All.
As a minimum, if a Publish All is done, that should include all files in the shared > assets folder of a Utilised DevPack resulting in an update of the file in (my case) the rw > elements > com.logrunner.blog folder.
So not critical because I have a work-around (relaunch Elements) but it is slowing the workflow down.
@tpbradley@dan - Just checking you have seen my PM’d project that demonstrates this annoying bug.
This is occurring when editing and developing custom DevPacks and so I appreciate the majority of users won’t experience it - doesn’t make it any less aggravating though.
I am still having to quit Elements, re-load the project and then do a Publish All, to ensure that a publish doesn’t leave any code behind.
In fact, I have now got Claude to add specific checks at run time to make sure all the published code is consistent as it was catching me out so often.
So hopefully the project I sent you (with Claude’s comments) will help narrow the issue down?
Hey @logrunner, We’ve discussed this internally and here’s what we’re currently wondering:
The system has a limit on the number of files it can actively watch, and we’re wondering if you have a lot of dev packs installed as each of those (and all the files in them) will be monitored by Elements/ the System for updates. If you blow past the limit, it will start to drop files and this is where the issues arise (a restart of the system obviously clears this).
Can you give us more details on your exact setup? How many dev packs do you have installed? could there be hundreds or thousands of files in them combined?
We didn’t manage to re-create it, but are taking a look at the sample project you sent again.
Can you confirm that you can re-create the issue with just this single Dev Pack enabled?
Please remove ALL other dev packs from the Addons Preferences window and restart Elements, before trying to re-create the issue.
Can you also confirm the version of macOS you are using?
It’s worth noting that even if you do a Publish All Files, the content in the Assets folder isn’t sent unless you restart Elements after a DevPack change that affects the Assets. I would think that it should do?
Retested as requested with ALL other dev packs removed from the Addons window — only the publishbug demo pack installed — and Elements restarted before testing.
The bug still reproduces with a single dev pack installed.
Elements 3.0.2 (24355), macOS 26.5.2 (build 25F84), publishing to a local folder
After the restart, an initial Publish All correctly deployed the pack’s shared asset (fresh copy on disk — the known restart workaround working)
I then edited only components/shared/assets/version.php (changed a version string), touching no other file in the pack
A normal publish did not deploy it — the published copy’s content and modification time were unchanged
A subsequent Publish All Files also did not deploy it
I then quit and relaunched Elements and did another Publish All with no further edits: the file deployed immediately
So within one Elements session, an edit to a shared/assets file is never published — regardless of publish type — until the app is quit and relaunched. Pack count doesn’t appear to be a factor: this run had exactly one dev pack registered, containing 6 files.
I re-ran the same test with the example pack — baseline Publish All, then an edit to only components/shared/assets/version.php, then a normal publish in the same session without restarting. The shared asset deployed correctly, which never worked before.
Thanks @tpbradley for sorting this — it removes a restart-before-every-publish workaround from our whole workflow.
