Phosphorus and Lime

Two ways to create a ADODB Lite object. The second, using DSN (Data Source Name) allows you to set a flag that will count updated rows even when they aren't changed. (This is significant if you are a defensive programmer like me.)

Simple Instantiation


DSN Instantiation


References:
ADO Documentation: DSN Support

keywords: php, mysql, adodb, adodb_lite, update, count, dsn

I've updated the Greqo code to handle classic and beta accounts transparently -- well, almost. If you set up your script with the basic undifferentiated settings, like this, it will still work for either type of account. However, since it will try to authenticate using the Google Account ClientLogin interface as a first step, classic accounts will throw an error here. Nevertheless, as in the test script linked above, the request should still succeed.

To clarify how it works, consider the following code samples.

User Settings and Greqo Setup


Generic Blogger Post
note: this will work for either type of account but will throw an error for classic account when it tries to authenticate under the new Google Accounts API


Now, if you know you are dealing with a classic (non-beta) account and wished to avoid the error warnings, remove the Google authentication part and just manually set the Blogger api url:

Classic Blogger Post


Greqo Google Code Home

A couple weeks ago, Google announced the release of a new Blogger Data API for PHP: Ngeblog. Ngeblog uses the Zend Framework's HTTP Client to authorize Google accounts -- and therein lies its one fatal shortcoming, at least for me. The Zend Framework requires PHP 5 -- and most my hosts are still on PHP 4.4.

So I've developed an alternative that uses the PEAR HTTP Client and Magpie XML classes. It's called Greqo (Google REQuest Object -- though it's not really an object-oriented architecture.) I've created a Google Project for it and uploaded it there. Right now, it can authenticate a Google account (using the ClientLogin interface), retrieve a Blogger feed, and post a new entry to a Blogger blog. I'll add functions to edit and delete posts as I have time.

It's simple to load. Just start a session and call the greqo_driver. An example:



A full demo is available in the Google Code repository:

http://greqo.googlecode.com/svn/trunk/test/basic_get_control.php

Noticed I was getting an unusual number of hits all of the sudden on my mushpup wikka wiki. At first, I thought: "At last, people are finally catching on."

Then I looked where they were coming from. Primarily, Google. But they weren't searching for "mushpup" or "passwords". Instead, it was more like, "nubile rapidshare" and "Aneta TeenPinkVideo". Hmmmm... I don't remember posting anything about pink videos.

Well, I did a Google search on these terms, found the mushpup listing and figured it out: wikka comment spam.

Googled for a shotgun solution. Didn't really find one but came up with one pretty quickly.

Three steps:

1. Backup your database
Now as good as time as any. Especially if you screw up one of the next two steps.

2. Change wikka.config.php settings
The key ones default_write_acl and default_comment_acl. Set to the following:



This will limit page editing and commenting privileges to registered users.

These are the global settings. Access can also be limited on a per-page basis by the through the admin web interface.

info on other settings here: http://wikkawiki.org/ConfigurationOptions

3. Delete any existing spam comments
This is pretty easy since they're all in a simple table named something like wikka_comments.

phpMyAdmin makes it simple to delete the offenders. Or you could use a statement like this:



(81.177.22.243 was the actual ip adding most the spam.)

keywords: wiki, wikka, spam, comments, comment spam, mysql, phpmyadmin

This is one of those things I keep having to look up. It involves the old target attribute you use in <a> links to open the link in a new window. This attribute is deprecated in XHTML strict and HTML 4.0 -- or so I hear.

Here, in any event, is the workaround:



So this:



Would become this:



(The rel attribute is not necessary but can be used for javascript functions to the same effect.)

credit: phpfreaks.com

keywords: link, links, anchor, blank, _blank, target, xhtml

I've been wrestling with some complication with sessions and domains names recently, so this thread on comp.lang.php caught my attention. It says basically, if you're not careful, you could have a user on your site lose their session if they were to somehow move from say http://yourdomain.com to http://www.yourdomain.com, your user will lose their session.

I offer my solution to this problem here (I think this is the same concept used by most popular applications such as Joomla). The functions below may also be useful. The first has evolved over a long period of time. It hasn't failed me yet, though I don't know that it is the optimal solution to this particular challenge.