getRootPath function in global.js causes problems (Mark?)

TomTester

As noted in various topics (e.g. this or this) the getRootPath function defined in /js/global.js
is causing some headaches for applications that 'pack' CSS and/or JS files and in the process
remove the related <SCRIPT and <STYLE tags. e.g.

JQMedia uses this: jqmediaPath.webRoot = jqmediaPath.getRootPath('script', 'src', 'js/global.js');
JQThickBox uses: Vanilla.webRoot = Vanilla.getRootPath('script', 'src', 'js/global.js');
(plus there are others...)

In these examples getRootPath code determines the path by parsing the 'src' field of the <script tag.
Unfortunately, packers like vzippy & vanilla packer remove the <script reference and as a
result the getRootPath function returns 'false', resulting in broken links to media etc.

I'd love to see an alternative solution to fix this once and for all and to create a best practice code snippet
for developers, to use in their add-ons.

I'd love Mark's input in this as well.

TT.

Edit @ 8:12pm - removed PathFinder code, you can look it up yourself in js/global.js

Dinoboff

getRootPath doesn't cause any problem, and that's not really the problem of mark but our problem Tom.

Mark just added the function but doesn't use in the core. And the problem is with Vzippy and Vanilla-Packer. we have to find a solution. I found one for Vpacker. For V-zippy the solution is quite easy.

TomTester

Dino,

Sure, getRootPath is not really to blame, and neither is Mark. This was more of a 'pull-in quote'.

The problem really lies with the ingenious but unreliably implementation of determining the path
with getRootPath used in in JQMedia, JQThickBox, iBox etc.

That particular implementation uses getRootPath to obtain info about vanilla paths, yet as we've
found out, deriving these on-the-fly, predicated on the presence of <script...> and <style...>
isn't a *reliable* solution going forward.

Now we can ask everyone to change their use of getRootPath, but why force everyone to add a
complex piece of code when a simpler, secure & fool-proof way to provision the vanilla paths
may exist.

Your solution (is that the one you reference?), requires developers to change their add-ons
to check for the presence of another add-on, a slippery slope indeed, or the alternative is to
require users to change core files/add-ons themselves (aka, 'hack' the vanilla core or add-ons).
IMHO neither is preferable.

Since I consider this root/core functionality, I asked Mark for his $0.02 (or CAN$0.025) I hope he reads this ;-)

TT

MySchizoBuddy

Dinoboff code checks for packer and makes changes to getroot path
jqmediaPath.getRootPath('script', 'src', /js\/packer\.php.*$/)

Stash

TBH, provided there's a (preferably documented) way for extension authors to code a single extension that works with or without the packer, I don't see the problem.

TomTester

Schiz, it required Stash and yourself to change the code to add a specific exception for a specific add-on.

It solves the path problem ONCE for ONE add-on, instead of solving it ONCE for ALL add-ons. The code
still assumes (and requires) the presence of a script tag referencing global.js (or now also packer.php*)
to function properly.

I feel that:

#1 path info is best provided to add-on JS-files by the core so when core method changes, all add-ons
are automatically up-to-date and do not require manual updates, saving us all a big headache.

#2 path info should not depend on the presence of something that isn't guaranteed to be there (either
global.js or packer.php).

I really can't see why anyone would disagree with this.

Better to change it now rather than later, when other add-ons have similar requirements (e.g. advanced
page caching add-ons or my practical VZippy, see my next post in vzippy thread)

TT

MySchizoBuddy

what came of this issue.
Do we have a solution to this.

i'll prefer to change it cause its creating problems fror JQmedia users.

TomTester

Nothing came of it (AFAIK) other than that I abandoned my first attempt at a Vanilla add-on (VZippy) ;-)

JohnnyFive

Hate to bring up old threads, but i'm currently running into this. I have over 800+ errors from JQThickBox b/c it can't find the base URI. Anyone have any ideas or an idea on how to fix this?