So, I did a little experimentation, and I was able to seamlessly integrate Serendipity into my existing website via Smarty, some CSS, and changing just a couple of links!
The result is the website you're currently reading!
This means I can now offer trackbacks, comments, RSS feeds, and all the other stuff a modern blog should offer… and with minimum fuss and with a lot of standards and security. I wish everything I did was this easy.
I've been wanting to improve — no, rewrite — my blogging software for a month
or more now. The more work I've done at work, the more efficiently I've felt I
could handle it. I've learned a lot of ins and outs with
superclasses, and figured out how to tie things together much better. However,
I've also noticed, in reading and analyzing blogs, that there are a lot of
standards that I just don't know enough about or simply don't have the time to
implement ("the more work I've done…" has been something like 70 hour weeks
recently). Things like trackbacks, and RSS/Atom feeds, and comment
moderation/blacklisting, etc. I certainly have the skills, but do I have the
time? Not really. I still have a goal of writing some lightweight blogging
Cgiapp. However, for now, that's on hold so I can focus on
family, myself, and the next round of
Cgiapp improvements. In the meantime,
i've been seeing a lot of stuff about Serendipity, and I
thought I'd give it a try. Here are the results! It was super fast to setup,
and I hope to import all my old entries from my own system to it, once I can
see how entries are stored in the DB. So, you can now keep track of me via
RSS… Read away! Update: I'm liking S9y even more: it uses
Smarty for templating, which means I'm able to modify
it to look like it was always seamlessly in my site!
Well, it's official: My IT Manager convinced those in the upper echelons (well, considering it's a non-profit with only around 20 employees, that meant the president and the CFO) that (1) he and I need to attend a PHP conference, (2) due to the amount of work we've been putting in to bring money into the organization, cost shouldn't be too much of a deciding factor, and (3) php|Tropics isn't too expensive, especially considering the sessions involved cover some of the very issues we've been struggling with the past few months (PHP/MySQL/Apache and clusters, PHP5 OOP, PHP Security, test-driven development, Smarty, and more).
So, we're going to Cancun in May!
This is incredibly exciting! I've never been to Mexico, nor even a resort, so I'll finally get to find out what my wife and friends have been talking about all these years. Plus, the conference is top-notch — many of the presenters are well-known in the PHP community, and have blogs I've been following for the past year. (I only wish that Chris Shiflett's PHP Security series wasn't running head-to-head with the PHP5 OOP Extensions and PHP 5 Patterns sessions; I suspect Rob and I will have to do a divide-and-conquer that day.)
Drop me a line if you'll be attending — I'm looking forward to meeting other PHP junkies!
I've been extremely busy at work, and will continue to be through the end of March. I realized this past week that I'd set a goal of having a SourceForge website up and running for Cgiapp by the end of January — and it's now mid-February. Originally, I was going to backport some of my libraries from PHP5 to PHP4 so I could do so… and I think that was beginning to daunt me a little.
Fortunately, I ran across a quick-and-dirty content management solution yesterday called Gunther. It does templating in Smarty, and uses a wiki-esque syntax for markup — though page editing is limited to admin users only (something I was looking for). I decided to try it out, and within an hour or so had a working site ready to upload.
Cgiapp's new site can be found at cgiapp.sourceforge.net.
Shortly after I wrote this original post, I figured out what the strength of Gunther was — and why I no longer needed it. Gunther was basically taking content entered from a form and then inserting that content (after some processing for wiki-like syntax) into a Smarty template. Which meant that I could do the same thing with Cgiapp and Text_Wiki. Within an hour, I wrote an application module in Cgiapp that did just that, and am proud to say that the Cgiapp website is 100% Cgiapp.
1.5.3 fixes an issue introduced by 1.5.2 that creates a performance hit whenever the run mode is being determined by function name or CGI parameter. More details on the Cgiapp download page.
At work, we've been developing a new platform for our website, based entirely on Cgiapp. This week we released the first stage of it: garden.org and assoc.garden.org. These should stand as good testament to Cgiapp's robustness!
With all that development, and also with some communication from other Cgiapp users, I've made some changes to Cgiapp, and release version 1.5.2 this evening.
1.5.2 is mainly security and bugfixes. Error handling was somewhat broken in
1.5.1 — it wouldn't restore the original error handler gracefully. This is now
corrected. Additionally, I've made
run() use the array returned by
consisting of the
$_POST arrays — in determining the run mode.
Finally, I've modified the behaviour of how
run() determines the current run
mode: if the mode parameter is a method or function name, it cannot be a
Cgiapp method or a PHP internal function. This allows more flexibility on
the part of the programmer in determining the mode param — words like 'run' and
'do' can now be used without causing massive problems (using 'run' would cause a
race condition in the past).
As usual, Cgiapp is available in the downloads area. Grab your tarball today!
I don't know why I never bothered to look this up, but I didn't. One thing I
typically do in my parent Cgiapp classes is to pass
to the template. I just found out — through the pear-general newsgroup — that
this is unnecessary: use
$smarty.server.KEY_NAME to access any
your template might need.
A new Cgiapp user reported they had stumbled across the project in php|architect! It's in the current, October 2004 issue, in the News section, prominently displayed in the upper right corner of the page. The announcement blurb is straight from my freshmeat project page for version 1.4. Cgiapp is carving a name for itself!
At work this week, I discovered a bug with how I was calling
set_error_handler() in Cgiapp's
run() method. Evidently passing a reference
in a PHP callback causes issues! So, I corrected that.
I also made a minor, one-character change to
query() to make it explicitly
return a reference to the
$_CGIAPP_REQUEST property array.
You can see full details at the Cgiapp download page.
Cgiapp 1.5 has been released; you may now download it.
This release fixes a subtle bug I hadn't encountered before; namely, when a
method name or function name is passed as an argument to
was receiving the requested run mode… and then attempting to process that as the
mode param. The behaviour is now fixed, and is actually simpler than the
previous (non-working) behaviour.
Also, on reading Chris Shiflet's paper on PHP security, I
decided to reinstate the
query() method. I had been using
$_REQUEST to check
for a run mode parameter; because this combines the
$_COOKIE arrays, it's considered a bit of a security risk.
creates a combined array of
$_POST variable (
$_GET) and stores them in the property
returns a reference to that property.
run() uses that property to determine
the run mode now.