Wedge

And yup, the original stuff is awesome; I grew up on re-runs of Pertwee and (Tom) Baker :D Oddly enough, the Hartnell/Troughton era isn't actually shown all that often here in the UK even on the 'Dave' channel (which is basically a channel born out of buying up broadcast rights to most of the BBC's back catalogue)

As far as the Christmas special goes, I still want to see the bit mentioned at the end of The Big Bang - where he answers the phone and it's a king or queen on board the Oriental Express, in space, with an Egyptian Goddess on the loose. I'm hoping that's going to be this year's Christmas special (after all, we've had an Agatha Christie based episode, we've also had something on board the starship Titanic, so something on board a space-bound Oriental Express is not out of the question)

I find coding to be somewhere between art and science, so having a rhythm to work with stimulates my brain through the tedious bits and counterpoints the exciting, daring artistic bits. Or something, anyway.

The plugin manager is undeniably my 'baby', and it reflects in the amount of passion that I have for it, that I'm not only working on it, working on all its mechanics but also in developing plugins for it, and that as working as it is, it's still very much a work in progress.Well, plugins had to be dealt with sometime, and it was at the stage where I couldn't let it pass any longer without doing something to it, so I started really figuring out the mechanics of it - and after that, it was simply the period of time it took to solve the underlying issues around the plugin manager's behaviour. I'm still wrangling with some of it but the core system works rather well.

I did get the feeling that you weren't that interested in writing plugins - and that's cool. I like writing plugins because it means that stuff I wouldn't put in the core, I can put in plugins, and it means that functionality can be developed in relative isolation, rather than having things that interact with each other like most core stuff.Heheh, well, part of the appeal for me was the chance to really make something of the package manager in some fashion. It isn't a bad tool, but it needed some serious love and attention.Hmm, I understand the reticence, not least because there is simply so much that interacts with it, it has so many consequences, and most of them have to not only be gotten right, but to avoid making a hash of it, most of them have to be figured out in advance.

I don't have a problem with releasing the demo as it is publicly (but not releasing a downloadable demo yet, there's still stuff too broken, like board access not having a working UI) and doing that after the demo but the longer it's left (and in particular after 1.0), the harder it's going to be to do.

Much as I stated with the dropping-bbc-in-favour-of-WYSIWYG, it's something that if we're going to do, we pretty much have to do it now rather than later.

The converter can be fixed up after the event. The core support, though, can't - because if it's left past 1.0, it's not only importing but upgrading that's going to be problematic - and that's a scenario I don't want to go down if at all possible, just because of the nightmare scenario it causes generally. Far better that we put the core in the core and have the converter deal with - measure twice, cut once, rather than measure three or four times and cut twice.

(5 modified, 13KB)

Revision: 1134
Author: arantor
Date: 14:51:19, 26 October 2011
Message:
! A bit more of the plugin stuff for the repository handling. It's still not finished either but hey, might as well commit it anyway. Also, be sure to lock out the plugin upload/download if gzinflate is not available. (ManagePlugins.php, ManagePlugins.english.php)
! New hook for CAPTCHA handling, if a plugin wants to extend the existing CAPTCHA framework. (Subs-Captcha.php, ManagePlugins.php)
! New hook for deleting members in bulk. It doesn't replace delete_member, because depending on what you're doing, it may not make a lot of difference whether you get them one at a time or in bulk. But there is a benefit to having the bulk query - for if you do actually do big deletes that hit lots of people at once - and unlike delete_member, delete_member_multiple can also rewrite the delete list if needed (e.g. to protect against certain users being removed for whatever reason. Use with caution!) Also note the delete_member hook itself has changed, to provide both the user id and name, not just user id. (Subs-Members.php, ManagePlugins.php)
! New hooks for Who's Online. One extends the list of actions that have to have permission in order to be visible, the other provides the entire dataset to hooks. While it might be practical under some circumstances to offer per-entry items to a hook, if there's going to be a query to get data (e.g. much like there is with topics, you want to be sifting that out before querying) (Who.php, ManagePlugins.php)
----
Modified : /trunk/Sources/ManagePlugins.php
Modified : /trunk/Sources/Subs-Captcha.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/languages/ManagePlugins.english.php

I have to admit, Japanese music hasn't ever really been my thing; I'm not an anime fan though I suspect it's because I've just never found quite the right material to introduce me to the genre properly, but my tastes are pretty specific for things I really get into.

Another one that's quite good for coding, daft as it sounds is:

Why is the Rum Gone? - Remix

So the small logo was updated in the main files - perhaps the favicon needs updating as well?

I've covered myself by putting in a little disclaimer as to the basis on which it is used. Unlike the original x-bitmap file, I'm using PNGs with the content in. I'm kind of hoping that someone points it out so I can show them where the GPL allows me to do exactly what I'm doing.

Sure it's possible. How rugged it'll be is another matter entirely.

In recent browsers, there is the notion of localStorage, a browser-side storage area that is bigger than cookies, not shared with the server unless JS instructs it to be (via normal HTTP requests etc). I won't get into the details of implementing that part, since it's not like there aren't tutorials throughout the web on the different browser implementations including some mini libraries that abstract that stuff away.

The real problem that you need to solve is the mechanism by which you're triggering a 'save' to be made and when to clear that save, as it were.

There are two principle ways of triggering a save, you can either do it from a JavaScript setInterval call, which will run every x seconds and you pass a function to it to indicate what it should do every x seconds. It's pretty trivial at that point to scrape the elements on the page and dump them into a localStorage container.

Off hand I'm not sure how you'd trigger firing the reload-from-localStorage when on the next page, perhaps run a setInterval again, see if the form's empty and whether there's anything in localStorage.

As for pruning, in the 'thank you for submitting' page or whatever screen appears after saving a ticket, just insert a line to clear localStorage.

---

There are two other solutions that come to mind.

1. Use a browser that doesn't have this problem. I don't seem to have any trouble in Chrome with navigating back/forward on pages with forms in.

2. Add an event to the onBeforeUnload handler, which checks to see if there's any content in the page and warns users about leaving the page. It need only be as complex as:


Of course that relies on MantisBT not putting any other events in onbeforeunload (if so you'll have to do more complex things!) and expand the checks to anything else you care to use, but the principle is sound.