Wedge

Would it really make things simpler...? From what I can see, it would shorter one line by a few dozen bytes, that's all. Also, loadLanguage is only (a bit) slower when base_theme_dir is enabled, if you're not using the default theme. Because it comes after it in terms of priority...

So, basically, I think these would be the wrong reasons for removing support.
The good reasons would be: (1) I don't know a thing about this feature and don't even know if it's documented somewhere, (2) if I don't know about it and it's probably not documented, considering that whenever I need something implemented I do it myself, I guess I myself see no reason to support something that I don't either need or know about...

Really, do as you please!

As I said before. This file date business is temp stuff. I'm planning to get rid of it as soon as you implement language file caching.
But until this is done, I have to do it... And checking for the file date of two folders (one when default theme is used) once per page load is quite fast really... The only issue being with windows and still.

No... I think what Pete means, is that since Wedge is going to be provided on the basis that "new updates are simply by dropping the updated files", the goal is for users not to have to modify their files manually.
So, you should understand this as: we're going to update the language files -- and we're going to be the only ones who can do it.

I'm guessing if you want to add your own language strings, manually and all, you can always use Custom.language.php... (Which I'm not even sure is a feature in Wedge?!)

Regarding the cache, so... I've finished implementing the filemdate check, and unfortunately it's not as solid as I thought. It should work properly on a Linux server, but when it comes to my Wamp install, my last modification date for the languages folder dates back to my last SVN update on it, rather than my last file change inside the folder... So it means it's going to work on a regular install, but not on my local install. Bugger! Now how do I deal with this... Is it a Windows bug? The php.net page on filemtime doesn't mention it...

Just to keep you posted...

- Fixed a surprising bug where strpos($del, $latest_date) would return false even if $latest_date was in $del... Because it was an integer. I thought PHP did some typecasting before a strpos, but apparently not...! So it means that this caching feature was pretty much broken since the beginning...
- The code doesn't (yet???) support (or care for) other themes. I figure you'll want to add support yourself :)
- Finished implementing per-language caching, i.e. generating 'script-french' and 'script' files depending on your language.
- Added support for plugin language files.
- Added a $settings['js_lang'] array. It is serialized in a similar fashion to $settings['registered_hooks'], which I'm not super-happy about, but it's still fast enough I guess. 'js_lang' is unserialized to an array of serialized arrays, so basically it looks like this in the end: array('script-' => array('index, Arantor:ThemeSelector:SkinSelector')) (<== SkinSelector being the language file inside the ThemeSelector plugin.)
- 'js_lang' is supposed to help in two ways: (1) if the script ID is missing from the array, it means there are no languages to be included, so we can directly include 'script-1234.js.gz' instead of adding the language string. (2) Supposedly, when we do loadLanguage, we can first test for file changes (I'm not recording this yet...), then if changed, go through js_lang and remove all JS files that use our language file.

As indicated in an earlier post, the main issue with js_lang is that it makes it impossible to test for changes to a file like 'JS.french.php' if the file is never loaded otherwise. I'd recommend maintaining a database of changed files somewhere, and then checking for changes before doing the wedge_cache_js test/call.
So... What do we do?

So what's the resulting output?

That's the whole point of the sandbox, actually... :)Hmm, it's odd, did it work earlier...? Because it looks like those lines were already broken before I did my Settings.php change.. Anyway, line 1836, replace with:


This is untested but it should work... (I'll be cooking up an even better version later today, that doesn't care about the length.)I've never had such any problem...?!
What's in your HTML head?Ah, sorry, can't help... :(

What about this one btw..?


--> basically, it just records the level of the first curly (so that we can find its closer easily), then it removes everything before the closer. (Also, the last $i call should ensure it doesn't increase it again because it's done through the for() loop... Oops.)

Well, it goes through loadLanguage all the same, doesn't it..? And loadLanguage is the perfect place to monitor changes... Heck, I just checked -- it even does a file_exists on any language file you're going to load, meaning that the file stats are cached from that point on, meaning you can get the filemtime for free, meaning doing a check there is a no-brainer.
Of course it means that if you have a special JS file like JS.english.php that you only load for JS caching, it'll never be seen as out of date. Thus we could have some additional cache check somewhere else... (e.g. in add_js_file)I don't know what base_theme is, but what I know is that I've never delved into alternate themes, had a few back in the day but now it's default only... I wouldn't know where it slows Wedge down, really. (Although there's quite a lot of code for alternate theme language files in loadLanguage...)Hmm, yeah, I guess so...
Wess/Subs-Cache aren't tested for alternate themes anyway. I mean, it's pretty much as if theme support was broken/removed for me. For instance, if you have a 'Wine' folder in your alternate theme, the CSS cache will much certainly save its files in the same folders as the default theme's...

Anyway.