DW Extensions: What, Where, Why, How?

[hen3ry]

It seems there is more than one meaning for "extension".   The one I want to discuss: files an individual  DW user creates, fills with code, and places in a dedicated folder, in the case of Macs and the latest DW:

   ~/Library/Application Support/Adobe/Dreamweaver CC 2017/en_US/Configuration/Commands/

These are usually in HTML--JS pairs, e.g. Extension1.htm  and Extension1.js, containing --respectively--  the initialization and the implementing JavaScript code for what the extension does.  This results in the DW menu item

     Tools-->Commands-->Extension1

which activates the extension.    It has full access to the DOM of the current file, so all sorts of transformations are possible.

Q1:  What's the definitive, unambiguous description for this kind of extension?

- - -

I write extensions for complex tasks that I do often in my workflow.  For example, the built-in tool

     Tools-->Clean Up Word HTML

only does part of the clean-up I want to do, so I wrote a variant that does what I need.  

This capability is vital to my workflow!

- - -

When I debug extensions,  I edit the extension files in the above-named directory, then I use a command hidden in the "insert" palette that reloads all the extensions in that directory. (In recent versions of DW CC, doing this causes my DW to crash.  The only workaround I can think of is to quit and re-launch DW to trigger extension loading.)  Then I activate the extension and see what happens. Sometimes I trigger Alerts in the code to tell me what's happening.   Rinse, Lather, Repeat.  Classic printf debugging.

Q2: Is there an alternative development flow?  

Q3: The ExtendScript Toolkit (4.x) is an extended-JS debugging environment: Is it capable of debugging DW extensions as defined above?  If so, how is this initialized? 

Q4:  Or, ...what?

- - -

Q5.  Are there any web forums or similar resources specifically supporting this kind of DW extension development?

TIA

[pziecina]

Had you asked this question 5/6 years ago the answer would have been much simpler.

Answer then - An extension is any file with the mxp/zxp file extension installed using the extension manager.

Now it is not so simple, for one thing Dw does not have an extension manager unless one uses a 3rd party product. Users have to download extensions from Adobe -

https://helpx.adobe.com/dreamweaver/using/extensions.html

Many users will follow the procedure you are using for making extensions work in Dw, which personally i do not recommend as it is very easy to corrupt the Dw installation using that method. The other problem with it is that Dw in its 2017 implementation has not just a large amount of unused files/folders that are left over from old features that no longer work, it now includes files/folders from the Brackets code editor which do not conform to the Brackets method of installing or even writing extensions.

There was talk of updating the documentation for creating extensions for Dw, but I have not heard any information on the subject for months, more info may be available in the Dw pre-release program if you ask there, (Preran​ could you ask if any new info is available please? thank you in advance).

Now, having written all that, what was your question .

Do not use the extend script toolkit to debug your js. I know this sounds odd but it is not the best tool for extending Dw, (in fact it is not for extending Dw) i use VS Pro to debug the js and Dw for the html, but whatever you use it is important to remember that the final files you wish installed should be made into an extension package and installed via an extension manager to prevent corruption of the actual Dw installation.

It is also possible to submit your extensions to the Adobe exchange for instalation via the cloud, but this is not a method i personally would recommend, as not only does it take time for the extension to appear in the exchange, it is limited to a small number of free submissions, (5 or 10) and they are available to everyone as there is no personal folder.

There is a dedicated Dw extension forum as a sub-forum to this one, DO NOT USE. I and a few others used to answer question in that forum, but most if not all those who helped in that sub-forum have left, and i never look at posts in that forum anymore. The reasons for that turn of events are various, but the lack of updated documentation for creating extensions, (the newest is for CS 5.5, that was 7 years ago before CC and before the extension manager was dropped by Adobe).

The problem with trying to answer questions regarding how you should create extensions for Dw, are given above and until there is better documentation, and an easier method of installing them, (officially) I cannot provide a clear workflow or reference any up-to-date methods for creation, but if you do have further questions please remember to post in this forum, (not the extension sub-forum) and i will try to help if i can.

[pziecina]

Just a few points before i forget.

If you use your method to 'install' extensions, any dot updates to Dw you install will overwrite your extension.

Any extensions you create without creating an extension package may conflict with newer versions of Dw, effectively rendering them useless, as there is no documentation or reference to them as an extension.

As an example, i created an extension for adding css flexbox/grids/multi-column layouts to Dw's css designer, but if Dw itself adds any of these items my extension will conflict with the Dw implimentation, so you have to check everything before installing any extension in a new version, (will never release the extension to anyone else).

[hen3ry]

Pziecina:

Thank you very much for your response!

Would it be OK to adopt the term "Command Extension" to describe the result and procedure I use? 

- - -

I've been doing this a while -- I don't claim to have carefully kept track.  Just did a quick look:  My earliest work I found on a Command Extension is 2009.   (What version of DW was current then?)   I've never had any problem corrupting DW.    If I recall correctly the worst problem:  occasionally, I'd botch something in new work and produce an extension that failed at DW launch extension-load time, or at hidden-command-load time.   DW would Alert about this, I'd remove  the extension, reload extensions, and normal operation was restored.

In general, after every major version update of DW, I copy my extension work files from

   ~/Library/Application Support/Adobe/Dreamweaver OLDVERSION/en_US/Configuration/Commands/

to

   ~/Library/Application Support/Adobe/Dreamweaver NEWVERSION/en_US/Configuration/Commands/

That's definitely quick-and-easy.  Almost always, as I recall, my Command Extensions functioned in the new version exactly as before.    

Looking at the example you give of adding an additional function to DW's CSS Designer, I can see how an extension of such sophistication might conflict with new DW features.   I think because I'm creating very simple extensions which only result in adding additional items to

    Tools --> Commands

and do not modify any other function or dialog/palette --some are "headerless", change nothing visible at all-- I'm at much lower risk of conflicts, essential zero.  What do you think?

How does making an extension package and installing it via an extension manager reduce the risk, especially as the extension manager itself is a 3rd party product?   Can that a 3rd party vendor anticipate the kinds of conflicts that might occur?

- - -

You advise that I not use the ExtendScript Toolkit.   I'm OK with printf-style debugging.  I'd be OK with an actual breakpoint-and-examine debugger too, if one exists and reproduces the full Extension environment and the data state -- the DOM of the current file.   Maybe I'm simply ignorant of how to make a typical (or a specific) DOM available in an external debugging environment like VS Pro.  (Please provide a link so I can take a look at this product).  Maybe I'm unreasonably fearful of potential differences in DW's JS implementation versus some other environment.  Or does VS Pro use the same JS engine?

One key reason I considered using the ExtendScript Toolkit is the hope that it provides a work-around to the problem I noted my OP:  for almost a year now, DW crashes whenever I use the "hidden reload".  (By the way, this problem was confirmed 10 months ago by a user on a PC-based DW release.)  I hoped that using ExtendScript Toolkit would be a work-around.

Anyway, I simply cannot figure out how to get the ExtendScript Toolkit to connect to the DW JS engine, so I cannot debug an activated Command Extension.

- - -

About submitting my extensions to the Adobe Exchange:   it would be GREAT if my extension work would be helpful to someone else! I'd be glad to share, but I doubt this is practical.  My extensions are all to support my workflow, which I think is very different from what most people use. 

- - -

You advise avoiding the dedicated DW extension forum.  OK.   I gave up on that sub-forum many years ago.  There hasn't been much traffic on that, and what little I found wasn't very relevant. 

- - -

About documentation:  In this particular case I'm not so concerned that the documentation doesn't show recent dates.  This is a basic, original, and truly vital Dreamweaver function –supporting user customization– and I'm happy that this function is being maintained and will apparently continue on in the future.   It's a brilliant design, and such things aren't easily improved.

I do wish there was some kind of active community, somewhere.   I assume the 3rd party vendors have their own network, one that doesn't mix well with individuals writing non-commercial extensions.

Thanks,

Henry

[pziecina]

Hi Henry,

you can call the extensions you create, whatever you wish, and 'command extensions' sounds good to me.

Creating an extension package, (zxp) would ensure any load problems would just give you a warning at run time, and cause no problems otherwise. The main problem in doing so is that adobe no longer produces an extension manager for Dw, and this is required to create the extension package.

The 3rd party extension managers work just as the adobe one would, if it was available, and are produced by dedicated and very experianced extension providers, (dmxzone and project seven).

Given that you do not plan to distribute your extensions though, your method of installing is probably sufficient, and as you do know what you are doing i cannot see any real problems, but if you ever plan on doing anything more complexed it would be worth learning the correct method.

Now to the js, Dw used to have an 'hidden panel' js watcher for monitoring js during extension testing, but unfortunatly this vanished along with many other features after CS6. If you know how to use a browsers dev tools, (js debugger) then you can test your javascript using this. The only reason i mention VS is that the debugger it uses is the one i use, (i have the program, so i use it) but any good debugger will do. There is a debugger in Dw2015, (have not checked 2017), that can be enabled by starting Dw from the command line, (sorry dont know the mac equivalent).

The extendscript toolkit is for extending 'other' adobe programs, not Dw, (don't ask me to comment).

There is a long story about the decline of personal Dw extensions, and all the blame can all be placed on adobe and it's lack of understanding regarding Dw in the last 7 years. No matter what you do, do not submit an extension to adobe for inclussion in its exchange, as i can guarantee it will be more trouble than it is worth, and that is not just my opinion, but also that of extension developers who actually make their living from creating extensions.

Hopefully Preran will provide more information about updated documentation for the creation of Dw extensions, as without this we are all working 'blind' so to speak. A few people in the Dw pre-release have created extension and both dmxzone and project seven also ocassionaly take part in the program, though if they would give away 'trade secrets' is another question, but that may be another route you could try to find out more, as currently i am the only one in this forum, (as far as i know) that has created extensions.

Maybe a member of the dev team will join in with more info that will help you, but with the next release of Dw only weeks away, that is unlikely.

[hen3ry]

pziecina:

About dmxzone and project seven companies, and their extension managers:  Thanks for your strong endorsement of both vendors; that's good to know. If I ever need a pro-level extension I won't hesitate to buy one from them.   I guess there is a small chance that using an extension manager may sidestep the current problem I'm having with DW crashing on "hidden re-load". They are both free, so as time allows I'll try them.   If this is an effective work-around, it is one that requires a distinct additional step in the dev cycle, so it is unlikely to be a time-saver, but .... we'll see.

At this point, I don't anticipate working on any Command Extension that's more complex than what I've described.  Every minute and unit of energy I expend on extensions takes away from developing content...  

About the 'hidden panel' js watcher:   I think I have a copy of CS6 lying around.  I wonder if it could be worthwhile to re-install and use CS6 for its js support and --presumably-- a non-crashing re-load function.   Can you give me a clue where the panel is hidden?

I do know, minimally, how to use browser-based js debuggers -- I use this method when I'm working with js library products (e.g. leaflet.js) which require non-trivial setup in my pages.  Are you suggesting that I include in some typical content page the code of a Command Extension I'm developing as an ordinary script, with some convenient trigger?   Then, yes, I  see that I can use the browser's debugger and my transplanted extension can access the DOM.   But are the JS engines guaranteed to be  identical?   I use a lot of search-and-replace ops.  I think I recall seeing subtle differences between "standard" implementations and how such operations are done in DW's js.  Similarly:  differences in the DOMs?

Could you say a little more about the command-line-launchable debugger in DW2015?   If I can identify that product I should be able to find the launch codes for Mac, in one version or another.

About the function of ExtendScript:   I examined lots of documents and I noted a certain ambiguity. Broad descriptions  indicate that these tools supported _any_ scriptable CC application.   Specific descriptions never included DW in the list of supported apps. Sounds like I can give up any hope of using ExtendScript for DW.     No need to comment!

About contributing an extension:  I believe we're all better off when we help each other, and --if I felt any of my DW extension work had any potential to help others-- I'd be glad to share.   Based on your advice, I'd find another way of doing that, something other than the official exchange.

About documentation:  Having recently-updated docs would definitely be a confidence-booster, and --who knows?-- there might even be some useful new features. 

Do I understand correctly that you've been building non-commercial extensions for many years and you're a community of 1?   Whew!     Lack of user interest and lack of Adobe support for personal extensions -- which is the cause and which is the effect?

A new DW release is imminent?  Great!   Here's hoping we see some needed fixes and some super-innovative new features.

Thanks,

Henry

[pziecina]

Hi,

First to the actual creation of extensions.

If you download -

http://help.adobe.com/en_US/dreamweaver/cs/extend/dreamweaver_cs5_extending.pdf

you will have the most up to date documentation available, much of what it describes is now out of date, but the procedure for creating extensions is well described, even for creating command extensions. The main section you will be interested in is section 4. Where the adobe extension manager is mentioned replace this with the 3rd party extension manager of your choice.

Do not worry about which js engine is being used, just remember that any code after ecma 4 will not work, and if you know how to use a de-bugger for script testing, that is the best and most reliable method of testing, as a lot has been removed and added to Dw since the documentation was written. Unless you intend to go back to CS6 for your actual work, it is probably not advisable to use CS6 for your extension development, though I personally am in 2 minds about that.

I've looked for the documentation for the js debugger in dw but it apears to have been removed, (maybe someone else in the forum can help? ) Preran​ can you check on this please, and provide the link to the pre-release, (will explain why pre-release below).

One person who used to be active in creating simpler Dw extensions is David_Powers​ who may be able to also help, and he was active in the pre-release the last i remember. Most of the others who used to be active in the Dw extensions forum, are no longer active in this forum or any other, (probably like me, are now getting too old for all the changes). The other advantage of joining the pre-release, apart from getting to know what is happening in Dw development, is that the Dw team will be able to provide you with more up to date information on how to develop and submit your extensions for others to use.

The sub-forum for extension development used to be very active, and often had very vibrant discussions between those developing personal extensions, and members of the Dw dev team. The changes to Dw and the dropping of the Adobe extension manager, (added to the decission to move adobe products to a subscription only) changed the target audience for Dw and moved it more to the none developer type of user. This target user base is i think changing, and hopefully newer documentation for the creation of extensions will help to revive the number of users developing personal extensions, as speaking from personal experiance the ability to add simple to build extensions, was part of the 'fun' of being a Dw user.

[hen3ry]

pziecina:

Thanks for your response:

About "extending" docs:    I downloaded the that CS5 pdf  in 2011.  Its predecessor for CS3, I downloaded in 2009.   I also have a hard-copy of the "Developing Extensions for Macromedia Dreamweaver 8" dated 2005.  By studying these documents, I see there is a common thread through all of these, something useful to be learned -- and applied with care, because, yes, some changes have been made.

ECMA?  ECMA 4?   Never heard of any of this --until just now, searching-- and I really shouldn't need to understand any of this history.   Yes, ideally, I should be able to work in a debugger to iron out any version-itis problems.   That is, a debugger that works with the specific JS engine I'm actually using to execute my extension code.   This does not seem possible at the moment.

Join in the pre-release program?   Never been invited, or seen any sign of an open invitation.    In general, I'm very reluctant to use  beta products, basically, because I have lots and lots of content to develop.   I have more than enough unpredictability due to shifts and glitches in officially released products.  (Example: Did something about the validator change radically in the last several weeks? If so:   That's potentially a big diversion from content development; may require modification of one of my extensions -- so... another reason to move forward in this discussion.)

Wow, I checked the extension development sub-forum periodically and NEVER saw anything approaching "vibrant", so maybe you and I are actually discussing two completely different sub-forums.  Have all the interesting discussions you saw been scrubbed from the Internet?  I'd definitely like to see them.

Yes, I agree that expectations for software development products have shifted.   I'm not sure that today's emerging consumers want to develop extensions at all.  I'm guessing "they" want an integrated development environment that does, well, everything.  

Note To All Readers: please do not read the foregoing as supporting removal of DW extension support.  "They" can be wrong, expectations and practices evolve.

From my point of view, at the moment, my biggest issue is finding/re-establishing a viable Command Extension development environment.  Oh, yes, one that will continue to function in the upcoming new release.

Thanks,

Henry

[pziecina]

Ecma is the standards body for javascript, the equivalent to the w3c for html/css, so ecma 4 would be the equivalent of saying javascript version 4.

Early versions of js back in the days of ie4 and nn4 implemented js with their own variations, which meant that one had to develop browser specific scripts. With modern browsers no matter which js engine they use, they will all interpretate js 4 correctly, so it does not matter which browser debugger you use, it will work with js for Dw.

The reason i suggest the pre-release is that a few of its members do develop Dw extensions, so along with the annoying to some, (maybe many) necessity to test the next version of Dw, you would also have the advantage of being able to ask others who develop extensions professionaly and get answers from the Dw dev team for more info on developing them for inclusion in the adobe exchange.

As for the sub-forum being previously vibrant, i am talking about the Macromedia days, (pre dw8), when adobe aquired Dw there was a large decline in posts about extension creation, and the introduction of the CC subscription model was i think the final end to meaningfull posts, unfortunatly all those early posts were lost when the forum formats changed.

Your question about the validator -

Yes, and it is changing constantly, and will continue to do so over the next year. The reason for this is because the w3c is considering marking all versions of html prior to version 5, as obsolete. That in w3c language means, do not use anything but html 5. It is also adding validation for html 5.2. The other thing to remember is that validators have all officialy been experimental for years, even the one provided by the w3c.

As for continuing to develop extensions, that is why we require updated documentation, as it was rumoured that it would at some point be possible to install the Brackets code editor extensions in Dw. If this will change how one writes command extensions i do not know, i do not even know if it will actually happen, but the first Dw users to know about it would be pre-release members.

If you look at the answer by Inayal in the following linked discussion, the link to the pre-release is provided, (i don't know if that allows you to join or just apply to join) -

https://forums.adobe.com/thread/2383378

[hen3ry]

pziecina:

Thanks for your reply.

JS standards, right.  In general, I'm strongly supportive of industry-wide standards, but we are talking about two entirely different environments -- I don't feel strongly that DWs internal engine must necessarily track those of browsers.  (When I get time I'm going to try to find the specific incompatibility I believe I recall in the search and search-replace functions.)

Sign up for pre-release.  OK, I did, downloaded CC2018, and launched it. The first item I checked was the "hidden" extension reload.  Yes, it crashes.  (Well, the first UI event following that, directed at DW or at the Finder, results in DW crashing.)  So now I can submit a bug report that is somewhat more likely to get attention.  

And, as you suggest, now I can ask the pro extension developers if they have encountered this hidden re-load issue; if not, why, if so, any workaround?  So... how would I actually do that? 

The vibrant days... OK, I get it.  I arrived roughly at the time of the last Macromedia release.    It is a shame all the history from those days was lost.

Validation.  Thanks for the advice.  I didn't want to hijack this thread to discuss validation. I'm doing some research about my issues and --if necessary-- I can start a new thread.   There is a connection: to take care of some setup  and after cleanup, I invoke the validator through a command extension. I need a working extension dev environment to track validation evolution. (Turns out I have DW CC 2015.2 still installed.  It does not crash when I hit the hidden reload extension command so I have an interim working extension dev environment.)

Documentation updates:  yes, I agree, there are all sorts of good reasons to keep the documentation current.  One of them is sending a message to non-commercial extension user/developers that Adobe understands the importance of these.  Another: the process of building/maintaining high-quality docs reflects back on the engineering and can result in higher quality work.  Well, ideally.

Thanks,

Henry

[pziecina]

Glad to hear you found a bug already

Preran​ can you reach out to Inayal for this person please, and ask her to PM him with details of how to start a discussion and log bugs/feature requests in the pre-release please, (my info may be out of date).

Henry.

The search and replace feature in Dw does not follow the same syntax rules as that for development of an extension. One is the for the code you would use in a web page, (that in the code editor) the js for extensions follows the rules for the 'background' js processes used by Dw itself.

[Preran]

Thank you, Paula. I have asked Lalita to take a look when she is free.

Thanks,

Preran

[hen3ry]

On the issue of search-and-replace syntax:  it seems to me there are three distinct syntaxes for a given search/replace task:

(1) The regex strings and options a user enters  in a search dialog box in the DW GUI.

(2)  The JS in a DW extension.

(3)  The JS in a script within a web page as received by a browser.

Case (1) is clearly different, as it enables non-programmers to do modify the content of the current file. Are (2) and (3) identical, or only similar?

[pziecina]

Item 2 is different to item 3 in that unlike js in a web page the search and replace has no references to any of the internal js.

Normally when you writes js, one has a referece to other js functions either built into code hints/completion (api's) or in a linked file. With extensions many of functions are not referenced as the files are part of Dw, and all the extension developer has is the function name.

Self contained extensions that do not reference anything in other Dw js files, do not have the problem, but if you build anything that requires you to use none extension files, you will find referencing anything outside of your extension will be something you must be aware of.

[lnayal · Accepted solution]

Thank you Henry for reporting this issue. This issue is there with DW 17.5 also on Win and Mac both.

We have logged a bug in our system for this.

We will prioritize this for fixing.

Please let us know if you face any other issue with DW.

-Lalita

[Preran]

Link to Adobe prerelease

Adobe Prerelease

Is there anything else that you required of me?

Thanks,

Preran

[pziecina]

Thanks Preran.

I am unable to find a reference regarding the js debugger use for Dw2015 and 2017, has this feature been removed?

I remember that it required Dw to be started from the command line, but as i had 'another version' available i'm not certain what code was required.

[lnayal]

Hello Hen3ry and others,

We have fixed crash with "Reload Extensions" with our upcoming build which is beta state.

Below is the link to access our pre-release portal and try fix at your end.

Adobe Prerelease

Thanks,

Lalita