Wedge

It's fast because it's essentially pre-cached. Most of the reason the calendar is slow is because it's not cached and is thus queried every page.

That, and the fact it does other stuff as well in a variety of ways...


Anyway, that's not really why I'm posting. Today's question regarding the calendar is regarding birthdays. I'd typically want to set up birthdays separately to the calendar, so I'm thinking I'd rather separate them out entirely, which means a new question as to plugins.

Specifically, let's assume the calendar is going to be a plugin. Should the whole support for birthdays be made a plugin too? (Note: even if I did pull birthdays support into a plugin, I wouldn't remove age/DOB from the forum, because it has other uses that are core, like COPPA type support)

I didn't discover it either until I started to use it, because I saw layers as this immutable concept...I actually thought the same to start with, and somewhere I managed to forget that, probably around the time I realised that from a plugin author's POV, there's no difference, and that a layer is semantically a block that can contain other blocks.Look at wesql, it's really similar structurally in this case. There's private variables (much like the template skeleton itself should be as only wetem needs to deal with it), the setup stuff and then public functions.

Ah, so it was me misinterpreting, my bad.

I always thought of layers as being essentially blocks that contain other blocks; there's no real special layer-only behaviour that doesn't logically also apply to blocks, with the exception of being a parent. So yeah, a single fused function would be pretty neat.

I'd also suggest that it is done using flipping and is done that way to allow for sanitisation, though that's just my gut instinct, there's no real reason to insist on it (much as there wasn't much need to sanitise what went into the old template_layers setup)I'm good with it being an empty array. I'd rather not enforce there being a sub-block defined by necessity.

OK, so what's been going on lately? Nao's been busy with a variety of tweaks and gouges to the source, but I've been busy working away on plugins.

(Yes, careful readers will note that we used to call them add-ons, but they're officially called plugins now after the big conversation we invited everyone into. It's a small detail but an important one and since it affects usability, we wanted to make sure you were all involved.)

Why am I writing about it now? Apart from the fact it's been weeks since our last blog post, I really wanted to pimp out the fact that plugins now exist for it - you see, last month when I talked about it, it was still just fresh off the design board, had a few rough edges but worked. Now, some of those rough edges have been smoothed out - you can, for example, actually delete plugins now once they're disabled.

But that's not really what I wanted to talk about. I wanted to talk about the plugins themselves, and I've attached a screenshot from the plugin manager as it is on my PC right now.

First up, you might be wondering why WedgeDesk is broken, when it would be a plugin I'd be more inclined to keep updated. Well, it's only because I very recently changed the hook mechanics in the display page, phasing out the old display_buttons hook and I haven't yet updated WD for the new hook, but that's something I'll do soon enough. (It's also, incidentally, how I realised it wasn't possible to delete a plugin that couldn't be enabled for whatever reason)

All of the other plugins were discussed in http://wedge.org/pub/6929/personal-plugin-showcase-yes-i-m-an-attention-grabbing-git/ - a somewhat aptly named thread, if I may say so myself. ;) If you're curious about any of the plugins I would encourage you to go read that thread, as it has pictures and more details about them.

It's actually listing them alphabetically, though I think I need to change that to include natural case sorting (r in reCAPTCHA comes after Z in the ASCII table, and it probably should discount the case) and I suspect the interface may need some changes going forward to cope with lots of plugins at once - but that's why I'm opening the floor now, so that if you have any thoughts about that, that there's a venue to share them now that you can actually see what having multiple plugins at once would look like.

Oh, and I suppose to validate that it's not some kind of random hyperbole - these are real plugins that can be used :)

It's been a fun period these last few days, kicking out small plugins - I've spent maybe an hour and a half per plugin, and in that time I've been able to establish that the hooks are present for the plugins to work with, and if they weren't present, to make them available; until I wrote the reCAPTCHA plugin, the hooks to extend the verification system didn't exist, for example.

It's also interesting in other ways, I get to test other systems in Wedge, and find ways to enhance them; one of the screenshots I've posted for 'Flitter' in the above-mentioned thread shows a 'Your settings have been saved' message - this is an enhancement I only added recently as I couldn't be sure whether saving had been done without going into the DB. It's a usability enhancement, and it doesn't require plugins having to manually support it; it's covered totally automatically for standard settings pages :) And I managed to find a small bug in the admin pages because of doing plugins, there's really no better way to test how things work than by trying to break them!

My plugins repo is not publicly available (though a few people do have access to it) and I certainly wouldn't call these release-quality, in almost every case it's to prove the system is up to the job, rather than to make sure there's plugins for everyone when we get round to doing some kind of launch (and I can't see my releasing the plugins before Wedge 1.0 gold anyway)

Sadly, I'm going to have to leave it here for now, it's late, I have a few things to do before bed, and even more sadly I couldn't find a good musical reference to leave in this post :( But as the philosopher Jagger once said, you can't always get what you want. But if you try sometimes, you might just find you get what you need.
But there you are, that's where I am right now :)

Revision: 1080
Author: arantor
Date: 01:12:38, 10 October 2011
Message:
! Generate the right URL if a URL is provided for admin item icons. (Subs-Menu.php)
----
Modified : /trunk/Sources/Subs-Menu.php

OK, so now I'm playing with it again, and either I'm missing something or it's still buggy. Right now it could just as easily be me, I'm not feeling 100% (it's gone midnight, the heating's off and yet I'm running a temperature to the point where I'm sweating :/)

Anyway, here's the deal. I'm hacking together a crude Share Topic plugin. Provides links to the FB like button, the Tweet button and the Google +1 button, at a topic level. It's also gotten me to create a new item at the top level for the admin panel where I've found a bug, too.

Now, because I like compartmentalising and easy-extension later, I put each of the three link buttons into their own mini template, and bind them into a custom layer that I add dynamically. For the sidebar it's just not a problem at all to do this, and it works just great adding my new layer as lastchild to the sidebar layer.

It's a bit more problematic adding it into the display template. Now, I seem to recall there being a discussion about mixing layers and blocks, and I was of the understanding that I could essentially create a layout like this:

default layer
  block
  block
  layer
    block
    block
  end layer
  block
end default layer

So there's me trying to add it into the template skeleton with:

To me, this should include the layer into the flow before the title_upper (where the upper title/nav links are, after the report-sent and draft-saved blocks occur), but it doesn't do anything.

Now, it may be that it's not supposed to be used that way, and I have it wrong. Or it may be that it's got a bug. At this stage I'm not particularly fussed which it is, because I can make it all work with:

It's not exactly the same but for the vast majority of the time, it's close enough. And of course I could easily enough rewrite it to use a block there which should work (haven't retested that yet) But I thought I'd clarify what it was supposed to do before I looked at changing it.

You're more than welcome :) It *is* about time I pulled my weight, so to speak :lol:

Now, if only we had an awards plugin... maybe that should be my next target, heheh...

I was going through the old topics in this board and came upon this one.

Having actually modified how custom profile fields work, I can say that in reality this was even more misguided than I suspected before; the amount of performance change by disabling CPF was negligible - but not because of inefficiency.

In fact, a cached version of the fields to use was stored and immediately available, so if CPFs were disabled, the code simply wasn't run.


I do see the point being made, and interestingly here we are 6 months later and having had a discussion about this very point, as has been discussed only today about splitting off the PM and memberlist features into their own plugins.

I think, though, that the way the discussion was reached was absolutely in spite of the above crap, and solely because it was noted that the plugin manager would make it vastly more feasible to make these things plugins.

Interestingly, even with the power of the plugin system, I can't really see CPFs being a plugin, or indeed some of the other 'more core' features, simply because while yes there is a benefit to be had, there are other things that have to be given up to achieve it.