Wedge

John?

Yes, actually I thought that was how it was done in the first place..?!
Code tags are parsed the same way aren't they...?

Of course, it won't fix existing posts but... Not much of a problem.

It's worse than that actually... If you try moving the popup, it triggers the zoomedia item as well.
I did get the close button to work, though... (?)

I don't remember having this discussion before..?

I had this mod installed on one of my earlier SMF1 sites, no longer there though, but I liked it...

Hmm, well... The problem with max-width: 100% in this situation is that you can click the item to view it at max width, like the 'resized' feature usually does. (But this, IIRC, only triggers if you set a hardcoded width on the img tag.)
Maybe an overflow: auto..?

Ouch, that's complicated...
overflow: auto works when applied to a container div (which we can insert automatically.) But it then means that you can't show multiple img tags next to each other...

Something tells me it's going to be a matter of compromise.

Isn't there a max-width:100% on these thumbs already..?

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