This is Part 1 of a small series of posts I'm planning on running that will cover
hacking (using the term loosely)
BlogCFC. For Part 1, my goal is to remove the use of the functions
getProfileString() and
setProfileString(). What's my motivation? Some hosts consider them a security risk, and block their use. This is the problem I was faced with, at least; and
I know I'm not alone! Not to worry, replacing them with XML functionality is a piece of cake!
"But Adam!" I can almost hear you scream… "You're using WordPress!" And indeed, that is true (much to my own chagrin). However, I am working on something sort of big, and when I launch it, I intend to move this blog to the new domain, and use BlogCFC instead of WP. That's my real motivation: Getting it to work for myself.
Ray has said that he is converting these functions to use XML
in BlogCFC6, and that the code is available in the SVN repository. I checked because I didn't want to waste time writing this code if he had already done it for me, but it isn't very complete yet — so there's not too much to be able to
rip off borrow.
Note that what I'm about to tell you has a few caveats. Namely, that you'll need to keep the file blog.ini.cfm in place, but its contents don't matter much. Also, I have not tested this on a setup with multiple blogs running from the same codebase, and I suspect that you would run into further difficulties if you were to try it. If that's the case, I suggest you hold out for BlogCFC 6. If there's interest, I might take a stab at including this functionality as Part 3.
The first thing you need to do is convert the INI file to an XML file. I've created one based on the default blog.ini.cfm file — though note that I took out the trackback spam list values for brevity's sake. Just open up your copy of blog.ini.cfm and copy / paste them over.
However, if we leave this as an XML file, there would be nothing stopping someone from grabbing your XML file and finding your mail server username and password, and other private information (if the org folder is web accessible, which it shouldn't be if at all possible). In order to protect against that, we'll take our XML, wrap it in a ColdFusion comment tag, and append the ".cfm" extension. This will stop people from being able to find your settings because pulling it up in a browser returns nothing. (You can also edit Application.cfm in the
/org/camden/blog/ folder to <cfabort> if the settings file is requested, but it isn't necessary) Here is the entire listing of
blog.xml.cfm:
[viewcode] src="blog.xml.cfm.txt" showsyntax=no geshi=xml[/viewcode]
You might have noticed that I converted all of the setting names to lower case. This is important, and I'll explain why just a little bit later.
Next, comment out the two functional lines of code in the
setProperty() function of
/org/camden/blog/blog.cfc (
just like Trond), like so:
[viewcode] src="blog.cfc.setProperty.txt" showsyntax=no geshi=cfm[/viewcode]
This will let us fiddle with the data reading without having to worry about data writing for a few moments. Now, with that disabled for the time being, let's alter the data reader code to use our XML file instead of the INI file. Open up
/org/camden/blog/utils.cfc and replace the body of the function
configParam() (after the arguments) with the following:
[viewcode] src="utils.cfc.configParam.txt" showsyntax=no geshi=cfm[/viewcode]
This will load our XML data into memory, strip the CFML comment tags, parse it as XML, search it using the XPath expression
settings/setting[@name='#lcase(arguments.key)#'], and return the value attribute of the first matching "setting" node found.
Again, notice that I'm using
lcase() on
arguments.key. This is because we can not be sure that the keys are always requested in the same case in other functions, and case matters when searching XML. So searching for "DSN" and "Dsn" could potentially return different values. To get around this, we're converting all requested key's to lower case, and earlier we converted all of the key names (setting names) in the XML to lower case. Now, searching for "DSN" and "Dsn" both actually search for "dsn", and return the expected value.
If we leave things in their current state, then your instance of BlogCFC will read its settings from the XML file. You won't be able to update those settings without manually editing the XML, because we don't yet have a facility to write changed settings back to the XML file. So to change a setting, first update the XML file, then go into your blog administrator and click the "Refresh Blog Cache" menu item.
In Part 2, I'll cover the new setting-writer functionality, so that everything works transparently, as if it were still using the INI file.
July 15 2008 by 
Adam
1 comments