« Plugin CSS in regular files?
Plugin JS language settings
Forcing maintenance mode first? »

Nao

  • Dadman with a boy
  • Posts: 16,082
Plugin JS language settings
« on January 25th, 2013, 06:50 PM »
This will act as a reminder to self to fix this...

Or if Pete can do it for me. Because it's plugin-related, I'm always wary of fixing stuff, even though I wrote that one particular feature.

So, in Subs-Cache:873, I'm doing the @language check for JS files, and it accepts plugin files as well. I just tested it, it works fine, except for the filename: it doesn't add the language name to it, unlike the non-plugin JS files.

Is this a plugin-related issue, or something I forgot at some point...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin JS language settings
« Reply #1, on January 25th, 2013, 08:25 PM »
Well, the add_plugin_js_file malarky is primarily just a wrapper around the internal JS loading business (or it should be), so any behaviour like that is not a plugin's specific bug, but a bug spawned out of the fact that the plugin loader has not been kept in step with the main loader.

In theory, the add_js_file and add_plugin_js_file should behave consistently from calling perspective, i.e. they add the file requested. If the backend wants to perform some magic, it should do it consistently the same for both.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin JS language settings
« Reply #2, on January 26th, 2013, 01:49 PM »
Blame me all you will, it won't do you any good... 8-)

Although in this case you're absolutely right. It looks like I always tend to forget to update the plugin function when I'm modifying the main one... That's valid for both CSS and JS. OTOH, I've long thought we really should merge both functions, even if it means having a slower function overall, because it'd be easier to update altogether.

So... I've updated the plugin function, not much to do, only had to add a global and an extra line to determine the language.
However, I'm not sure I'm "doing it right", even if it works... From what I understand in my code, Wedge first determines if the current JS file has language strings in it (!empty($settings['js_lang'][$id]]). If yes, it adds the language to the filename (but only if it's not the default language, i.e. English here and French on my local install). Then it checks for the file's existence, and if not there, it regenerates it. Only, that's only during regeneration that the file has a @language tag, and thus fills in the js_lang array with $id... OOPS.
Fact is, it WILL work, but NOT on the first request, but it won't even be noticeable if the first request is done by someone who's using the default board language... (Because in any case it'll have the same filename.)
Is it worth fixing or not?
It can be fixed, I'd think, by fudging[1] the language name at the end of $id in wedge_cache_js, and obviously by making $id a pass-by-ref variable in the param list. It's not very pretty, though... I could also pass the language name in the param list but it's already very long as it is...
The more I see that caching function, the more I'm scared by the sheer complexity of it, although it's nowhere near that of Class-CSS's... Then again, they do their job :P
Quote
In theory, the add_js_file and add_plugin_js_file should behave consistently from calling perspective, i.e. they add the file requested. If the backend wants to perform some magic, it should do it consistently the same for both.
Sure it should.
Then again, I don't tend to use plugins a lot... So I forget a lot, too.

BTW, Dragooon, I internally renamed Dragooon:MultiAttach to Wedgeward:MassUpload, is that alright with you? I'm not committing that without your permission, obviously, but I think we should have as much 'Wedgeward' plugins as possible, and this one would be a good example, having been partly developed by myself.
 1. © Peter Spicer, circa 201x.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin JS language settings
« Reply #3, on January 26th, 2013, 04:58 PM »
Quote
Blame me all you will, it won't do you any good... 8-)
I can blame me too for not keeping it in step :P
Quote
Fact is, it WILL work, but NOT on the first request, but it won't even be noticeable if the first request is done by someone who's using the default board language... (Because in any case it'll have the same filename.)
Is that 'first request' for any language, or first request for 'non default languages'?

Also, here's a thought to make it more complex. How does one call @language for a plugin's language file? Since the plugin's path is never exposed to the plugin itself (a plugin, by design, should never need to know where it actually is or rely on hardcoded paths, when $context['plugins_dir'] should be supplying it), it must somehow pass the plugin id, perhaps @language Arantor:plugin:file which could be fun if they have a separate lang dir like I tend to do on bigger plugins... @language Arantor:plugin:dir/file,Arantor:plugin:dir/otherfile
Quote
The more I see that caching function, the more I'm scared by the sheer complexity of it, although it's nowhere near that of Class-CSS's... Then again, they do their job :P
That is their job, yes ;) The entire magic process is complicated, I don't understand most of its details any more, I've sort of come to rely on them 'just working', even though I'm aware there are issues with the CSS loader.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin JS language settings
« Reply #4, on January 26th, 2013, 05:48 PM »
Quote from Arantor on January 26th, 2013, 04:58 PM
Is that 'first request' for any language, or first request for 'non default languages'?
For any language. But it's actually more complicated than that...

Anyway, I've found a few errors I made earlier, and they should be fixed now. I'm not sure why, but it appears that French users would see the English files regardless... I'm pretty sure it worked back when I wrote the feature!
I've gotten rid of $final_file in the function params (as it can easily be rebuilt), and replaced it with $lang_name, which is more interesting. This one is passed by ref.
Quote
Also, here's a thought to make it more complex. How does one call @language for a plugin's language file? Since the plugin's path is never exposed to the plugin itself (a plugin, by design, should never need to know where it actually is or rely on hardcoded paths, when $context['plugins_dir'] should be supplying it), it must somehow pass the plugin id, perhaps @language Arantor:plugin:file which could be fun if they have a separate lang dir like I tend to do on bigger plugins... @language Arantor:plugin:dir/file,Arantor:plugin:dir/otherfile
@language xxx does exactly this: loadPluginLanguage('xxx')... It's up to you what you put in it ;)
If you're telling me that a LPL parameter can have slashes in it, I'll just add a more generic [^\n]+ to the regex.
Quote
That is their job, yes ;) The entire magic process is complicated, I don't understand most of its details any more, I've sort of come to rely on them 'just working', even though I'm aware there are issues with the CSS loader.
Well, even if I don't get it anymore, I know I'm in a good position to at least understand what I was doing after studying it.
So it's my duty to fix the system whenever it breaks...
Just like I did now. Hopefully :P

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin JS language settings
« Reply #5, on January 26th, 2013, 06:10 PM »
Quote
@language xxx does exactly this: loadPluginLanguage('xxx').
Then it will be broken because all of the loadPlugin* functions need two parameters ;) They need the plugin id and the plugin file to load. I don't mind how we do that, as I suggested before we could accept it as author:plugin:file, explode on : then recombine the first two.
Quote
If you're telling me that a LPL parameter can have slashes in it, I'll just add a more generic [^\n]+ to the regex.
Well, there's no enforcement on what the id can be other than it has to be author:plugin and less than 255 characters (though, frankly, it probably should be alphanumerics only plus that middle : separator) and separating files to load with ,

Wait a minute though, if you're calling this for a given plugin, the implication is that you'll already have the plugin id... still gotta pass that through to loadPluginLanguage but otherwise yeah it's just a regular path that you're missing at that point.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Plugin JS language settings
« Reply #6, on January 26th, 2013, 07:19 PM »
Quote from Arantor on January 26th, 2013, 06:10 PM
Quote
@language xxx does exactly this: loadPluginLanguage('xxx').
Then it will be broken because all of the loadPlugin* functions need two parameters ;) They need the plugin id and the plugin file to load. I don't mind how we do that, as I suggested before we could accept it as author:plugin:file, explode on : then recombine the first two.
You should look at the source code before typing for so long... Basically it's doing that... :whistle:

Code: [Select]
loadPluginLanguage($exp[0] . ':' . $exp[1], $exp[2]);

$exp being the exploded string ;)
I haven't tested with paths yet, though...
Quote from Arantor on January 26th, 2013, 06:10 PM
Wait a minute though, if you're calling this for a given plugin, the implication is that you'll already have the plugin id...
Yes, I guess I could just pass the plugin id to it... But I think it could confuse people. For instance, if you have an index.english.php in your plugin, what does "@language index" want to actually load...? Maybe by saying "@language :index", where ":file" refers to the current plugin's file list, but... Hmm, I don't know, it's alright as it is for now...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Plugin JS language settings
« Reply #7, on January 26th, 2013, 07:48 PM »
Quote
You should look at the source code before typing for so long...
I'd rather clarify it here before wading through code, much easier to understand when the intent is known as well.
Quote
Maybe by saying "@language :index", where ":file" refers to the current plugin's file list, but... Hmm, I don't know, it's alright as it is for now...
I don't have a problem with plugins having to be explicit about it.

Nao

  • Dadman with a boy
  • Posts: 16,082
« Plugin CSS in regular files?
Forcing maintenance mode first? »