Photoshop 2019 plugin

Photoshop
1

Greetings,

I know there are plugins for PS 2019 so I am curious on how might one make one. Most people in my community use that version because of features that were changed in the later versions of photoshop and therefore making plugin is kinda tricky. didn’t find any good resources for it so I thought I would just ask. Any information is good. Thanks

2

You can use the old framework CEP.
That repo is a beginner guide, but at the bottom you’ll find links to the rest of the documentation.
It’s a royal PITA compared to UXP and whilst it is going to be phased out of Photoshop I don’t see why it would stop working with older versions.
Also be aware that it wasn’t developed after 2015 (IIRC) and so the API is missing any methods for PS tools added after 2015 (although there are ways around that in most cases).

It’s been years since I did any CEP and I believe the old ExtendScript debugger doesn’t work with modern operating systems and so you’ll need the new VS Code extension instead.

There are probably some more knowledgeable people here who might correct me - I know a few of our users still support legacy CEP plugins.

3

So, the only reason I assume UXP is not working with older versions is because of another forum post where a developer actually answered with these news. If you know of a way how to make it work for older version, that would be lovely though!

4

UXP only works for versions of PS after it was released - Adobe would have to go back and add the UXP JavaScript compiler to older versions; which I’m sure would be a monumental task.

Perhaps the solution is to recreate the 2019 functionality via a UXP plugin?

5

Most people don’t want to switch to newer versions just because they are very well acquainted with the older. Recreating the 2019 functionality might be more of a monumental task than just remaking the existing UXP plugin in CEP. That is assuming it is possible!

6

I suggest just learning UXP and creating the plugin in that. No sense in learning an old system like CEP.

What I have found from some users who ask me about running my plugins in CC 2019 is that many of them are running older bootlegged Photoshop versions, which is the reason they are still using 2019.

Anyway, CEP and JSX are dinosaurs and are extinct as far as I’m concerned. UXP is better in every way. No way I would even consider making a CEP plugin or JSX script ever again.

7

The problem is that the plugin is made. All I need is to get it into CEP. Not sure about the bootlegged photoshop situation in the community.

8

@ddbell haha! Preach brother!
I never want to set foot in the CEP saltmines ever again :rofl:

I have to agree; whilst developing a CEP plugin is still a viable thing to do in 2023 it’s only going to get harder, I doubt anyone will make a new debugger if the current one stops working.
Let alone the diminishing community of CEP developers to ask for help (it’s only been 3-4 years and I’ve forgotten most of it).

That 2019 version of PS will become obsolete itself in time too (I’m damn sure that I wouldn’t still be able to install from any of the PS CDs and DVDs I’ve collected over the last 25 years!)

9

No chance - CEP and UXP use completely different versions of JavaScript.
The only way is to build it in CEP.

10

The architecture is completely different too, in CEP you have a JS process running to manage the UI of the plugin (just like a web page) and then a separate JSX process that handles PS stuff and you have to have them both communicating back and forth, it’s a right palaver.

11

If you have not learned CEP yet then it is a huge learning curve. Not really worth the time to learn in my opinion. If you do want to learn it then the only really good documentation I know of is the HTML Panels coarse from Davide Barranca. It is a very good coarse to learn CEP it but not free. He also has a Photoshop scripting coarse to cover JSX which is also very good.

It is a huge task to take on and learn for something that is dying, especially if you are just catering to a community of people that won’t update Photoshop.

What I have found about the people are are not willing to get a legitimate version of Photoshop… they are not the type of people who are willing to spend very much money on a plugin anyway. So those would not be my target customers if I were wanting to spend the time to learn how to make plugins.

Just something to think about before you go and spend a huge amount of your time learning CEP… because it WILL consume a huge amount of time to learn if you are starting from scratch. UXP will also consume a huge amount of time to learn from scratch. However, at least you would be learning something that will be around in the future and not wasting hundreds of hours of time on something that won’t be around.

12

I agree with others… developing for CEP is much harder than UXP

  1. separated scripting from UI
  2. scripting engine is like JavaScript ES3 from 1999 (not kidding) does not even has .foreach and minificators will break the code
  3. action manager instead of batchPlay with much harder to work with syntax
  4. not really good debugging tool… you have to download different CEF.exe for different PS version
  5. not really good way to load/unload plugin… also manifest is XML instead of JSON and you have to restart Photoshop after every change to test it
  6. you need to sign ZXP package to make the plugin work or change the OS registry
  7. even if you have ZXP it will not install correctly so you have to get 3rd party installer or copy files manually or create your own for MacOS and Windows which for MacOS might require notarization

There are a few advantages but CEP is not really worth it. I mean do your own math for return of investment… but it could be easily between 200-500 hours to learn it from scratch to the degree that you could finish the project. So it would depend on your hourly rate and expected sales.

13

I learned CEP from scratch and it took me about 300 hours to build a production ready plugin - literally 10 hours a day for three months (I was paid to do it)!

1 Like
14

It was an absolute flipping nightmare

15

I will give it some thought and then decide but thanks for all the feedback

16

As a freelancer, it took me a while to build into my mindset the “Return On Investment” part. But after a few projects where the ROI was low, I have learned LOL. I had some CEP plugins I spent hundreds of hours on in the past and only got a few hundred dollars in total sales on. When I did the math it was like $1/hour. So I decided that just blindly developing something because I thought it was cool was a bad business model. Now everything I work on I try to figure in the potential ROI, which is sometimes hard to do but absolutely necessary to do.

2 Likes
17

One more perspective:

  1. I heartily agree with everyone that says to avoid CEP if you can. UXP is a better system, and is where the platform is headed. If you don’t need CEP, don’t do it.
  2. Unless you’ve got customers — that will pay you tremendous money — and have a valid reason for being on painfully outdated software other than general subscription-phobic harrumphing — supporting the past isn’t worth it. It’s a ton of work for a market that is, by definition, shrinking.
  3. That said, as someone that manages a plugin that runs on both UXP (PS) and CEP (Illustrator/InDesign) it’s absolutely doable to create a codebase that is 90% interoperable between both platforms and can be written with sane/modern code and tools. Here’s the general idea:
  • Build your plugin as a React App or some other framework that lets you pass in props/inject dependencies. Make the plugin app headless, insomuch as it makes calls to injected apis provided via these external props. This is most of your code and is sharable on both platforms. I use the same core codebase for PS, AI, ID, and Sketch.
  • Both your CEP plugin and UXP plugins can spin up their own flavor of your plugin app and pass in their own specific api via the props that allow the plugin to interact with the particular host system. CEP will require you to create a bridge of sorts that can serialize data in and out of ExtendScript if you need to use it.
  • ExtendScript is nearly ES3 (it’s actually slightly different, with some very annoying differences that you won’t find until Prettier starts formatting your code like a sane person would and breaks math order of operations). If you pick a bundler that can compile to an ES3 target (Webpack can, others might) and you polyfill stuff like JSON and modern Array methods, you can get a completely reasonable setup in the ES3 hellscape.
  • TypeScript is absolutely doable, and there are types for both UXP and CEP available, and you can extend your own where needed.
  • Exception Monitoring in ExtendScript is tricky but doable. You can’t get column numbers for exceptions, but you can get line numbers. If you configure your bundler to not minify your code, and write your own transport for getting exception data to your service of choice, you can capture errors, pass them back out of ES3 and then let the CEP side which is more modern JS recreate your exceptions and send them off to your service.

So that’s all to say, it’s hell, and I don’t recommend it if you don’t need it. But if you do decide to step off that cliff, you can make it work.

1 Like