I don’t use executeAsModal ANYWHERE in my Plugin, and it does a lot of different things. It opens/closes documents, it modifes the size of images, it works with smart objects, it saves outputs as JPEGS – and nowhere do I use executeAsModal for these operations, and nowhere does Photoshop appear to throw any errors related to me not using it.
I assume if executeAsModal WAS required for a given operation, Photoshop would throw some kind of error that says that it’s required, correct? Or does it not do that? And it’s up to YOU to figure out when it should and shouldn’t be used?
My concern is, it may work this way on my local machine, but perhaps if someone else uses it, and/or downloads the plugin, it may start breaking lots of the functionality – perhaps if the user has several plugins installed, for example, or if they’re using a different version of Photoshop that perhaps has different rules/requirements for executeAsModal.
Another question: Is there some Adobe documentation page that flat-out tells you: “Here are the operations where executeAsModal is required”?
So that is the explanation. Using version 5 is more future-proof. And it will ask you for executeAsModal. As far I know it is required for all actions except for a get and maybe multiget.
Is there any downside to publishing my plugin on the marketplace and offering it for download via Manifest Version 4?
Are there any restrictions Adobe puts in place on older manifest versions, or is there the risk that my plugin will get rejected/removed due to using that older manifest version?
I’d hate to have to go in and change a ton of my code to work with the v5 Manifest if it’s not needed.
executeAsModal wasn’t invented to annoy us. (Although I had that feeling a few times ) The reason is… if you have long-running script. Especially e.g.
Run PS action
Ask the server for something that can take e.g. 2 seconds
Run another PS action incorporating data from step 1 and step 2
If script is in stage 2. and the user clicks some buttons in Photoshop or another plugin will run something… then it might or might not invalidate some assumptions e.g. from step 1. Because if user changes active document in the middle of executions then some layers might be missing or other things can break.
But while your code is still within executeAsModal it does guarantee that the user or other plugin cannot interfere with your code.
As for Marketplace guidelines… I am not sure. I did not send the manifest version 4 plugin for a while but as far as I know it is not forbidden yet. But at the same time there are security concerns. Manifest version 5 includes the permissions while in version 4 it is just missing but working therefore it is less secure.
So here’s what I found in the Adobe documentation on this:
In order to allow plugin developers to gradually move to the new model, Photoshop 2022 supports both the original and the new JavaScript modes. A plugin uses the apiVersion field to specify which model it uses.
apiVersion of 1 signifies that the plugin is using the original Photoshop 2021 implementation.
apiVersion of 2 signifies that the plugin is using the new modal JavaScript paradigm.
With the introduction of apiVersion = 2, the original implementation is formally deprecated, and support for apiVersion 1 will be removed in a future major update to Photoshop. → https://developer.adobe.com/photoshop/uxp/2022/guides/uxp_guide/uxp-misc/manifest-v4/photoshop-manifest/
This basically seems to be saying: For the time being? Plugins can continue to use the older apiVersion = 1, which does not utilize the executeAsModal functionality. However, at some completely unknown time in the future, Adobe may entirely stop supporting the apiVersion 1 – meaning any published plugins that are created around that framework could get removed from the plugin marketplace, and/or stop functioning suddenly for users, obviously having the massive potential to piss off whatever potential users you have that were depending on the plugin for their workflow. This could lead to a spike in negative reviews complaining that it stopped working, loss of customers, etc.
For the time being, I’m probably going to just stick with the apiVersion 1, since it would be a massive pain to completely re-do all of my code around this new apiVersion 2 and convert everything over to executeAsModal. There’s risk involved in this approach for sure, since Adobe has said quite explicitly that this version will stop being supported at some unknown time in the future. But it’s something I’ll just delay making the change on for now – so I can focus on releasing my plugin, marketing it and driving some traffic to it, I can then see how much people even like the plugin and how badly they want to use it – and if it seems worth pursuing further and investing more time/energy into? THEN I could work to make the switch over to apiVersion 2.
This is the fundamental risk involved in trying to build a revenue stream around something that you do NOT have control over. Updates, sudden changes, new company policies, can yank the rug out from under you, and force you to either adapt or get screwed. I fully knew the risk going into this project, so I can’t say I have much to complain about. I’ll just have to put it on my to-do list to migrate over, and modify the code accordingly, if the plugin starts to get some traction over the new few months.
What Jarda Mentions about user interacting with PS is a real concern in API 1. Not just the PS menu but also Photoshop keyboard shortcuts.
I have automation plugins that run batch processing. Before API 2 this was a huge pain because users would want to multi-task on their computers and do other things while the batch was running. Just trying to press “alt+tab” at the wrong time to switch back and forth between PS and other programs would trigger the alt key and use it together with a selection the plugin was making, or invert the mask it was making, etc. This would mess up what the plugin was doing when in API 1.
I was responding to a LOT of tech support for this. API 2 has fixed that.
That’s a fair point. Personally it seems very obvious to me that if there’s some Photoshop automation operations running, it’s best to just, leave the computer alone and let it run – and not try to minimize Photoshop, then open up a different browser window and start surfing the internet. To me that’s just common sense.
You know what they say though: “The average person has an enormous amount of common sense because they haven’t used any of it yet.”
While it may not be the best practice to multi-task, a ton of my users do and it created an extra tech support workload for me which I didn’t like to deal with. With API 2, I have not heard of any problems at all from my users who multi-task. My clients are all professional photographers and most of them use their computers for work so they multi-task to other work, not to watch YouTube. Some of the batches will take hours as they are batching 1,000s of images. It might not be best practice, but many of them do it and I’m glad that it works for them in API 2 so I don’t have to keep answers tech support questions about it
I have asked internally, and there are no immediate plans to shut down Manifest v4/API v1 plugins; developers will have more time to acquaint themselves to the newer API.
Which by the way I strongly suggest to move to, also because all the new goodies in DOM development (to which Jarda and I have sweated over for months) aren’t available to v1.
) The reason is… if you have long-running script. Especially e.g.