Plugin Directory URL for external Javascript file

judebert · Post by **judebert** » Wed Dec 10, 2008 11:56 pm

I feel silly for asking, but rest assured I tried this site's search (which was useless) and a site-specific Google search before asking.

I'm working on a plugin that uses Javascript. Rather than copying the whole script into the <head>, I'd like to just reference the .js file. But there are no guarantees on what directories are writeable; therefore the file will have to be included in the plugin directory during the plugin installation.

But then how will I refer to the javascript file? When I make my link, can I make the reference with $serendipity['serendipityHTTPPath'] . '/plugins/' . MY_PLUGIN_NAME . '/thefile.js'? Is there any condition under which the plugin directory won't be located there? Perhaps there's a plugin already doing this that I could look at?

I could supply the javascript through an external plugin hook, but starting a new instance of Serendipity seems like a lot of overhead just to download a single Javascript file.

I could force the user to enter the plugin URL, but that always confuses them.

I just want a canonical way to reference files in a plugin directory.

Post by **Don Chambers** » Thu Dec 11, 2008 12:31 am

Microformats uses js on the backend, but I see the path to the js is hardcoded, and does not use any kind of variables.....

Post by **garvinhicking** » Thu Dec 11, 2008 9:39 am

Hi!

This is definitely a problem, yes. Usually there are two solutions:

1. The painful one for the developer: Use the external_plugin hook to emit the JS. The "livesearch" plugin for example does that to wrap the Javascript.

2. The painfule one for the end-useR: Make the HTTP path to the plugin directory configurable, prefill it with an expected format like plugins/serendipity_event_blabla/ - then users who use symbolic links or subdirs must adjust that. The majority of plugins use this approach.

Regards,
Garvin

judebert · Post by **judebert** » Thu Dec 11, 2008 7:49 pm

Ugh. So it's either pain for me or pain for them, eh? Decisions, decisions...

Am I correct in saying that the external_plugin hook requires loading up the entire Serendipity framework? It seems like a lot of overhead for a single Javascript file, especially if the installation has a lot of plugins. Or am I overstating the performance cost?

The idea behind external Javascript, of course, is to enhance speed by allowing multiple simultaneous downloads. (As opposed to locally included Javascript, which gets downloaded in the same connection with the HTML document.) The big question becomes: will calling the plugin through the external_plugin hook require more time on the server than saved with simultaneous connections?

Post by **garvinhicking** » Fri Dec 12, 2008 11:53 am

Hi Judebert!

You are absolutely right, and not underestimating the performance cost. Which is why I usually recommend the "pain for the user" way. Since the probability of users having the default path without any symbolic links or subdirectories is quite high, most people don't even feel the pain for configuring the variable. Only those users with subdirectories need to, and usually they are more professional so that they know about the need for configuration.

RobA: Yes, people like me have a directoriy plugins/additional_plugins/ which points to the CVS repository, so that I can install every plugin without the need to seperately download it. This means that my HTTP path for those plugins is serendipityHTTPPath + /plugins/additional_plugins/plugin_name/blah.

Regards,
Garvin

judebert · Post by **judebert** » Sat Dec 13, 2008 4:19 pm

Thanks, Garvin. I think maybe my best bet is just producing JavaScript in the <head> while Serendipity is already loaded. I appreciate the help!