No, 0.7 is not released yet (believe me it is far too difficult to implement at the moment and only one feature is written), but I’ve put one of its new features into my WPGet installation here.

If you click on the comments link on any post (in the left-hand pane on the main site), you will get a little window containing the comments. You can click the close button on the left, which, obviously, closes the window and the expand button on the right to view the comments on the actual blog post.

Please note – this does not currently work properly in any version of Internet Explorer. IE6 panics and doesn’t render any style (it appears inline and very broken) and IE7 ‘features’ this annoying z-index bug, so the window appears ‘underneath’ the central content layer. Grrr. I’ve spent upwards of an hour attempting to debug and fix it just for IE, to no avail. I will endeavour to get it working soon, but not right now.

Ouch. I hate IE. Seriously, Microsoft should ditch the Trident rendering engine and rebuild it from scratch for IE 8. IE is broken.

I’ve tested it and it works in Firefox 2.0.0.1, Konqueror 3.5.5, Opera 9.10, Epiphany 2.6.12 (that should also cover all Gecko browsers). Confirmation for Safari support would be appreciated from anyone with a Mac (works in KHTML, though, so I imagine it will be fine).

It’s completely devoid of any styles and probably very unstable and buggy, but here’s a quick preview of what the new Ajax comments feature will act like in WPGet 0.7.

See the preview

Any comments, suggestions, things I’ve forgotten and of course, pre-emptive bug reports are more than welcome. Note – 0.7 is still a long way away (depending on the level of development time it gets, which may vary), there’s lots of new features still to do and some stuff I’m going to change to make the code leaner and easier for me to manage and other people to read.

The current code isn’t available as it’s really messy, incomplete, buggy and subject to major changes until the release. If someone really really wants it despite all that, though, I might be convinced to hand it out…

I’m working on the new inline Ajaxified comments thing in the next WPGet release (where you click the comments link, and theoretically a little box will pop up and show you the latest comments on that post). I have a question to ask as to how best achieve a solution to a problem I’m facing. If you don’t want to delve into the technical reasons behind this, skip a couple of paragraphs and rejoin. I really do need the users input here as to what the best way of fixing it is, so please please please tell me what I should do.

I’ve run into an interesting problem. In order to do this cool Ajax stuff, I need to pass some special information in the URL so that WPGet springs into action and delivers the Ajax content you requested (pulling out comments out for each and every post would be far too database intensive).

However, WPGet is included by another page, which means that the user doesn’t access the wpget.php file directly, all of that is be handled by the master script. That makes it a pain to get that special information passed in the URL, as I can’t control the master script invoking WPGet and change how it works.

Basically, if I cut the technical drivel, which of these solutions to this problem is better?

1. At install time, you have to paste two bits of PHP into your file – one snippet of code at the top to handle Ajax stuff (this is the new bit) and one where you want the posts to appear as normal. This would only affect people wanting the Ajax functionality.
2. Only one snippet to copy and paste, but we ask the users at install time which directory wpget.php will be located relative to the script calling it (index.php for example). In most cases, it’s the current directory (index.php and wpget.php in the same folder), so novices will leave it at that and there’s no problem. For people wanting to put it in /includes or whatever, they would have to remember to state this during the setup process.

   Technical talk – in this solution, when Ajaxing, we’d request the wpget.php script directly in the URL, along with our arguments, so therefore we need to know where it is relative to $_SERVER[‘PHP_SELF’]

Now, there’s clearly arguments for and against both and I don’t want to complicate the installation process too much. These measures probably won’t affect users not wanting the Ajax comments functionality, but I really want to keep installation simple.

I am relying on you to tell me which solution is best, as I’m not really sure. Particularly Lee, as you suggested this feature, what do you think is best?

Alternatively, I’m if (likely) being incredibly stupid, someone please tell me how to get the current file’s web-accessible filename from within PHP (not the filename of the file that calls wpget.php, but the wpget.php file itself).

Oh – forgot to mention this.

Reasonably soon, I will be releasing a new bit of code to the world. It was born out of some useful stuff from the Livelocity project – and it’s a PHP class that will automate the creation of tabs in a web page.

When I say tabs, I mean – the kind of tabs you would have inside a dialogue box in a desktop app to have lots of stuff in one window, whilst keeping everything organised. There’s currently no HTML widget which provides a tabbed interface out of the box, so you have to build the tabs yourself, with CSS, JavaScript and HTML.

This is where my code will come in – it’s some really easy to use PHP where you can simply call it and it will generate all the HTML, CSS and JavaScript needed to make a nice tabbed window (with Ajax capabilites and fallback for users without JavaScript).

I’m sorry if this makes no sense – it’s too late and I’ve been coding for too long. There’s a bit of cleaning up work to do on the code, so I’ll try and get it to you as soon as we’ve got the Livelocity Beta out the door and I have a bit of free time.

It’s likely (but not yet completely decided) that this will be released under a BSD-style licence (aka “take it and do what you want, but give me credit”).

Wow, that was a long time away from blogging (not). Forgive me if I’m brief – I’ve been typing almost all day, mostly PHP code. My eyes are almost bleeding after getting a nice solution to a nasty problem. I love finding solutions to problems, it’s awesome.

Development is coming along nicely, taking up almost all of my time. Thanks to the 25th of December, I now actually have the ability to purchase a MacBook now – but I’m not going to yet, because I am waiting very patiently for Leopard. In the long run, waiting will be a better thing to do. Believe me, it will.

Anyway, I think it’s photo time, don’t you?

» Read the rest of this post…

It’s kind of a fusion of ‘live’ and ‘velocity’. Don’t ask me about the name, I’m just a code monkey. 😛

But anyway – this is what I’m working on for a lot of my time at the moment.

Livelocity is a digital media marketplace for anyone. In the digital age, major labels and their top-down system of content delivery are irrelevant. Livelocity seeks to supplant that system with a new system that allows anyone to share and profit off of their art.

Livelocity will be available to the general public on February 14th.

If you’re at all interested in the sound of this, then why not head over and sign up for the beta testing period? It’s not done yet, but the code factory is working pretty much full time (when I can get to a computer and code anyway) so it should be here soon.

Oooh – also, if you know of any musicians or any kind of media creators that might be interested in being part of Livelocity at the beta stage and beyond, then get them in contact with Livelocity’s Chief Idea Factory, Chris Van Patten.

I guess I’ll be back tomorrow with a seasonal and festive post (and you better watch the top right hand corner of the site too :D), but if I’m not, have a great Christmas. I’ll no doubt blog again before the New Year.

Well, I wasn’t not-free before, but as of today my Christmas break officially starts and I have days all to myself – in theory.

With a bit of luck – and provided that there are no unforeseen circumstances, development efforts on Megaphone and Livelocity (I think I’m allowed to say that :P) can accelerate to hopefully full speed.

WPGet is currently on the backburner, but idea suggestions are wanted for the next version.

I’ll obviously still be trying to juggle my time between the two major coding projects, keeping myself sane by messing about installing stuff, breaking stuff, reinstalling stuff and breaking it again and of course trying to not spend too much time on the computer too.

Tomorrow I may be on and off development (or running between rooms) as I’ve got to do a nice, fun Windows XP reinstall on another machine. But considering how long Windows takes to install, don’t be concerned. 😀

Apologies. It’s been literally months since I did my last tutorial here. Most of my tutorial effort has been focused on FOSSwire. Anyway, I’m back now and thanks to a request from Nick I’m starting a new multi-part tutorial today.

Now this has been covered in many places before and the subject is object-oriented programming (OOP) in PHP. For the purposes of this tutorial, I’m using PHP 5.1.6 on Linux, but all of this should work on PHP 5.x on any platform and most of it will work in PHP 4.x.

» Read the rest of this post…

You might notice that WPGet hasn’t been getting much development time recently. Basically, I was really happy with the 0.6 release and we’d had no reported problems, and I had no new feature ideas at the time, so I left it.

However, I’ve been scribbling down ideas for WPGet 0.7 and I’ve got some cool stuff I want to do. But what do you – the users think? Please feel free to contact me in any way you want (comments on here are fine!) to let me know what works for you, what I should add and what sucks beyond belief.

A few ideas so far are below. Please note – these ideas are subject to being scribbled out, and to more being scribbled down. This list doesn’t guarantee a feature will make it.

• New style system – the output from WPGet will have templated styles (plus custom stylesheets as well, and original mode)
• Perhaps generation of images (for off-site use, in forum signatures etc) from WordPress posts?
• Support for WordPress author, so you can see who wrote what in the WPGet preview.
• Stabilise the multi-category support (currently considered beta quality in 0.6)
• WordPress page support? (Is this even needed?)

UPDATE: Forgot to add – test it with WordPress 2.1

Any idea with a question marks on it is definitely not guaranteed.

So, tell me what you want and I’ll build it!

I’m really sorry about the title. Coding for too long* makes me go crazy.

Anyway, as you might have guessed, it was about time for another Megaphone source release, and here it is. The offending messy code has been eliminated for now, and I’ll add it back and and tidy it up when necessary.

Instructions for installation are in the archive in the INSTALL file (Windows users should open the .DOS.TXT files, as they are Notepad-friendly).

The archive includes the current PHP source, .htaccess files for mod_rewrite (required!) and a database skeleton SQL file.

Let me reiterate – Megaphone is not ready for the prime-time. It’s pre-alpha, pre-release, in development software. It has a tendency to eat your pets if you upset it. 😛

All the relevant stuff is in the archives available at the project page.

As ever, it’s released under the GNU General Public License, making it freely distributable and all that open source stuff. Share your code!

* Well, it’s been 6pm until 10pm last night, about an hour this morning and 4pm to 7pm this evening. But it’s awesome and I really do love doing it. It’s probably good thing the only thing I really do is tech…