I hadn't looked into it before, but your change made me realize that my local install capitalizes month names in French, unlike what should be done. It works here on wedge.org, but not on my local install.
Oh yeah, it's probably that...
:-/Problem is, I thought that these months were stored in there to be used in things like the calendar, where you show JUST the month, right..? And a lowercase month name looks silly, I guess, as a title...
Why? Why serialize it twice? That's just overly complicating the matter (and is why I want nothing the hell to do with it) It's an array, not an array inside an array.
We're really not serializing things twice, except if the submitted string is serialized, which means that the caller code is expecting to get a serialized string back when stuff is retrieved from the database. It's just a 'protection' against bugs... Other than that, everything's serialized just once. (Or never -- in the case of a non-array.)
The more I think about it, the less reasons I can think for this to fail... The only issue right now is with empty arrays. If they're not initialized, it's impossible for Wedge to tell that we should return an empty array. For instance, if 'js_lang' is not initialized, it's an empty string. Thus we're not turning it back into an empty array. Thus $settings['js_lang'] is an empty string, rather than an empty array, when js_lang hasn't been set yet. It might create some confusion/errors. The logical solution would be to either store ALL array-types variables in install.sql (with a default set to "a:0:{}" or whatever the content is to represent an empty array), or have fallback code for every occurrence...
Maybe I could/should simply do a quick commit at some point -- the bare minimum required to make it work, and if it fails to work correctly, then we can easily revert it.
In other news, I've just finished implementing block variables.
e.g. in the main skeleton, we have a <linktree> block, right? And it's called *again* but manually if in a topic page. I already worked with this before and gave up on it because I can't define two blocks with the same name. Then it occurred to me today that I could simply store the variable list inside the block name... Eh, why not? Then it works. I just need to extract the variable list at render time.
So, we have something like this...
<linktree />
<content />
<linktree:1 />
The second one calls template_linktree with the first parameter set to '1'. I've invertedt the two variables so that $on_bottom is set to 1 in that second call. It works perfectly...
:)Now people are finally going to be able to call a single block multiple times, either with multiple variables or simply entering dummy variables like:
<my-block:to-the-left />
<my-block:to-the-right />
If you have several variables to pass, just separate them with commas (<linktree:1,2,3 />)
There's just one weakness: you can't pass strings between quotes or anything with spaces in them. I decided against it because it would slow down the code for nothing IMHO. Really, if you're declaring a variable inside a skeleton, you're only telling the block what behavior to use in that position... No?
Of course it would be cool to have something like <title:"Hello, world!" /> and create a block that is a title saying that. But it doesn't sound too realistic to me.
This isn't something that's impossible to implement. It's just that it makes the regex longer, more complex, and I don't really trust long regexes, at least not too many...
;)So, what do you think...?
