Because I can't be bothered to get my webspace reactivated until my parsing code is working, I've been testing my scripts on a test area I set up on the Ukastle server temporarily.

After many many long nights and hours just thinking about it, the parser script FINALLY WORKS!! The parsing bit where some code is replaced by other code worked from the start, however when a page was requested, the page contents needed to be converted into a "string" whereby the page becomes part of the code, so that some parts of the code could be replaced with other bits of specified new code... and this "file-to-string" wasn't working. I got that working after a while and came up with a whole new problem: the php script inside the file that was sent through the parser wasn't being executed. So if I wanted a file to be included at the top of a page, it wouldn't work... I've spent the last 4-6 hours working on it and finally got a working solution. Things aren't totally perfect yet, but I think I'm out of the thick bit of the woods...


This is how an example page now looks normally (note where the TEST LINK to ukastle is)
http://www.ukastle.co.uk/test-area/index.php

And this is how that file looks after being sent through the parser (also try and find the TEST LINK...!)
http://www.ukastle.co.uk/test-area/Page ... =index.php

In that second example, you can only find the TEST LINK if you know how to view the source of a page (in Internet explorer I think you go to the VIEW menu, then down to 'source'), because the page parser sees a direct link without these [  ] around them as being unauthorised, and therefore the link is disabled. Bigger picture: if my home page is hacked and links to porn sites added, the parser will disable them!

--

edit: I am now further improving the power of this script. My site went down before because somebody hacked in and uploaded pages to imitate the Natwest banking site so as to get card and pin information... the webhosts realised and disabled the site.
NOW, the parser script comes into play again. This time, the page won't have the one or two lines of special code in that the parsr is looking for, and so the 'default' value is set... once the script is complete, this will show a warning dialogue about the page that was attempted to be opened, and will contain a link to view the page at the visitor's own risk. If the link is clicked, the page will be shown, but bits will still be parsed if the page is deemed a risk otherwise.
For example, this is one of the pages that somebody uploaded to my site (I have edited it so no details get passed on... it just LOOKS like it will do stuff - it doesn't actually do it)
http://www.ukastle.co.uk/test-area/logon2.html

And this is what happens when the file runs through the Parser (as it will by default)
http://www.ukastle.co.uk/test-area/Page ... ogon2.html
(notice how the security risks get disabled)

_________________

After almost 3 months, Simon Cornwell has updated his site, here.

Then there was a flood.. Simon C has documented his (fairly) rare Eleco GR 525.

Latest update is the GEC8285 railway platform fluorescent lantern which must be long extinct and I doubt if any made it into collections.

A railway platform lantern like this is still one on my "wanted" list. Hull and Scarborough still have a fair few in use.

_________________

Crumbs, would have thought they were all long gone.  

Simon has now documented the "more common" GEC8288 railway platform lantern as well as his Thorn Beta 5 with the incrediably rare vertically grooved bowl

I may have confused the issue there!
I think they're more like the 8288 lantern that are surviving. Anyhow, I still want one! Selby station has some chain-hung lanterns that are so obviously GEC design, as they look just like the top part of an 8288.


The bowl on the Beta 5 looks awfully similar to some that still hide away round the back of Leeds.

_________________

Well do you mean the GEC 8290.. ?  

um, yes!

_________________

Latest updates from Mr Cornwell are the SKX55/MI80 and the GEC8451.