Wedge

We could certainly do that, we could also push it into the main cache and make clearing that more prominent (which would clear everything)?

I'm not actually bothered by it, it is a link after all ;)

file_exists definitely uses the stat cache, glob I'm not so sure about but I can't see any reason it wouldn't be cached at the OS level. Benchmarking is useful - but benching it on Windows is less meaningful than benching it on a Linux server. Windows will give you the worst-case scenario for things like that.

OK, so I was contemplating how an arcade plugin might work, and in particular adding new games to one - as plugins themselves that depend on the main arcade.

And here's the weird thing, it occurs to me that we could do something truly neat.

As you know, the plugin manager works by the plugin-info.xml files, and the different XML indicates various things - there are XML tags for adding new bbcode, for adding scheduled tasks, and so on. What if a plugin could declare its own extra XML handlers?

So like the arcade plugin, it could declare a <arcade-game> block handler, so that arcade games could be bundled into plugins quickly and easily without having to do complex database changes or anything, just declare new items and let the arcade handler figure out what it wants to do with it.


In reality all we're really talking about is a hook in the enable/disable plugin routines that also passes the manifest SimpleXML object and plugins can register a hooked function for there. I don't think many would use it but it is certainly an interesting idea.

The DB layer won't help, certainly. But I consider the trade-off in performance for that component on its own quite acceptable for the actual increase in security it brings (considering third party modifications etc.)

The other major performance headache is post moderation. There's no way around it, it is a performance headache if it is turned on.

For all other situations, you'd need to compare them with as-close-to-identical setup, so any optimisation work you did for 1.x (e.g. turn off calendar, DB tables being InnoDB and appropriate table structure changes to convert from tinytext to varchar) would need to be mirrored in 2.x.

Also if you haven't already, switch the avatars to their own folder.

I think that would work pretty well, actually.Oh, some nice ideas there. We already get the list of who liked posts, so it's no stretch to also pull the timestamp of likes and figure out the last timestamp for a like on any given post.I know what you mean.

Both menus work here currently (Chrome beta, desktop)

I like the look, and the experience attached to the animation but it's gone over my head as far as figuring out how to fix it. I've always taken the view that I make it work, but don't necessarily make it pretty.

Going back to the overall topic, I really like how the Like button works now, took a little while to get used to it. Making that work via AJAX shouldn't be too problematic (I don't think you did that already?) but I do find it a bit complicated as to how we would display a list of the people who like something, not that I could ever figure out how the list should look when we do get it (as I'm not entirely sure we should use the popups as they stand, but I'm not entirely we shouldn't either)

Also, have you changed the font lately? Either that or my browser is rendering text weirdly.

Works exactly as expected here on Chrome on the desktop.

I like it. But I think I'd want to use it to really get a feel for it.