Wedge

rev 1875 -- ask() fixes.
(4 files, 3kb)

! These JS ask boxes look great... But they break stuff, from time to time. Confronted to a choice between an ugly confirm box for the 'Delete post' link, and rewriting the mini-menu code, I chose the latter. So, removed the 'custom' option to add onclick events. Because jQuery has a .live() function to attach events to objects that aren't created yet, I can simply associate the function to the requested class. The code is a tiny bit longer, but it's in the footer... Heck, who likes confirm() over ask(), I'm asking? Yeah, thought so! :P (Display.php, topic.js)

! Fixed icon alignment in Add Ban area. (mana.css)

! Commenazi. (ManageSearchEngines.php)

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.@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.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

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 :PSure 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.

Hmmm... Makes sense to ask these ;)
I don't think I would accept the drawbacks over the advantages, I guess...

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...?

Can someone test this site under an iPad now...?
I've added a minor change to ensure iPads don't change the main font size.


Please tell me if it works for you!

I was thinking of something...
Perhaps it's already implemented that way, but I doubt it.

How about having a function (or extend add_plugin_css_file or something to do it), that takes a request from a plugin to 'add some CSS to this or that general file'.
- It the file doesn't exist, just create it...
- If it does exist, then add somewhere in a variable that next time we flush the file (say, index.css), we'll need to get some extra CSS from that list of plugins, and add it to the end of our file. Or something.

That would save having to use an extra HTTP request or inline CSS for some minor feature we want on every page.

Then again -- maybe it's already all implemented... Maybe it's not even doable. But Pete asked me to open new topics for every little idea or suggestion I have, so there I am... :P

Not unexpected...
Technically it's all like I said... Before yesterday, there was a Safari header shared for all platforms. Now there's a Safari header just between iOS devices. It's still not enough, apparently.

So, yes, I could add a variable again... But what is it about, really? It's about element sizing. And what is the difference between iPhones and iPads..? Stuff that can be seen through CSS.
So the solution is to use a media query *even* when ios is already determined.
I'll look into that one... I've never used the DPI-specific ones. (Only pixel-specific. Although it could be enough, as the iPad resolutions are always > 960x640 anyway...).