I revise writing, a lot. I’ll revise after I’ve posted something, if it doesn’t ring quite right to the ear, rereading and tweaking a word here or there. Usually simplifying and deleting. I highly recommend William Zinsser’s “On Writing Well”…

Having used Microsoft Word for DOS 6.2 in ancient times, and watched my work disappear in the flick of a monitor, I also save my work, by reflex. A lot. This created a problem in WordPress 2.6. WordPress 2.6 by default keeps revisions. As many revisions as you click “Save” to keep your edits.

I saved a couple of versions of up-sell: if you pay us more, we can fix that…. I went back to open and edit it again a bit later. I got a 30 second timeout error from “wp-includes/diff.php?etc”, and the edit window for that post would no longer load. I’m pretty sure that is the script that works through the revisionings for the post in the process of bringing up the editing window.

I tested further — no other post had an issue. Just this one. Which makes sense. It is longer than most posts, it went through extensive re-writing and adding to, and the revisions must have been, well, there must have been a lot of them. Apparently enough to hit a WordPress or server limit, and cause a timeout.

I could still bring up the post on the weblog site itself. I did, and went to “View Page Source”. I copied the html and text from the page source, deleted the existing post entry, recreated it, pasting the page source back in, thus keeping blockquote tags and paragraphs and all the stuff I would prefer not to do all over again. [1] It also changed all of my punctuation to ASCII/html code like ’ (apostrophe) and “ (double-quote, open).

I re-published the post, edited the “Published” time to match when it originally was placed, made sure the permalink was identical to the original, and the problem was gone. For that post. The problem of revisions accumulating was still present.

There is (I love WordPress) already a Revision Control plugin. It allows you to limit the number of revisions WordPress 2.6.x will keep on hand. It was written by Dion Hulse, and it gives much more, well, revision control.

You can delete all of the previous versions – by individual post or page, so far, saving it with the revisions set to the disable – if you want revisions (I like to keep 4 back), save with the default revision setting (for me, 4) for the page. You cannot (yet) globally delete all revisions: “Disabling Post revisions on a post deletes all revisions for that post. However, Disabling globally does not delete current Revisions,” from Dion’s notes on the plugin. Too bad – that would have kept me from having to recreate that post I lost, possibly.

I would expect that WordPress will incorporate this into basic function. It’s too easy to end up with version after version after version, endlessly, without this kind of configuration being available at the admin panel.

— dsm

NOTE: visual editor in WordPress

I write in html tags. I don’t use the visual editor in WordPress. I found that it kept changing the internal structure of the html code and breaking things. It could not cope with placing a link in the title of a lightbox.js image, for example. I disable it for users, so it can’t mess with page or post structure, accidentally.

Embedding a link in the title for lightbox.js – granted, that’s not simple structure – you have to use &number; references to get the code to come through. The visual editor would completely break it by “interpeting” it better. The fckeditor plug-in was better – but it kept adding additional “fckeditor” tags trying to keep track of the nesting of the link in the title, so I deactivated it as a plugin and only use it in specific situations. But – that said – fckeditor did not break the nested html code required to embed a link in the title for a lightbox.js-displayed image.

Go back to article

The first was a failed comments function. The “Submit Comment” button failed to submit any actual comments. I hadn’t tested it. I was looking through google’s picture of the website, and found google complaining that /comments/feed (the rss url for comments) didn’t exist… OK, I can fix that. I’ll just submit an initial comment…

It would not submit, and further looking didn’t show any reason. I took a look at the comment code in a different theme for wordpress that did have the comment code functioning correctly, and by slowly changing one bit at a time, I got the code in this one to work

The second was minor – the “engineer” image was a relative link on the front page, and failed to translate (IT SHOULD!) to the comments page (WTF?). I changed that to a full URL and it should work now anywhere in the site.

—dsm

Store and Forward Messages wrote about the irony of writing about SSL certificates in websphere MQ, and also running a site only under https (which this one is) without a proper certificate… He’s correct, that’s bug #3.

With the DNS exploits running particularly rampant, it’s no longer workable to leave a mismatched cert. Firefox 3.x also makes certificate errors much more glaring and intimidating. I ordered and placed a correct signed certificate.

The site now runs on port 8443 on a separate server with the corrected cert. I’m still investigating being able to port shift from the original (virtual) server at port 443 to the new one on 8443 without having to have the 443 cert validated… ProxyPass in Apache works directly to dougmunsinger.com. The old URLs will work the same and still throw the same certificate error. Directly to 8443 after that, and no further mismatches…

I can live with running this on a separate server, but the apache2 config for virtual servers SUGGESTS that each named server can use a separate SSL cert and it doesn’t work that way. All the virtuals use the first certificate encountered in the config.

I used the capability of the WordPress application, then had to step back to the static pages and re-adjust them to fit the changes in WordPress. WordPress was providing a better basic underlying structure than the original site.

This design is WordPress based.

Rather than integrating WordPress with existing static pages, I started over. I can restyle the site independent of the content. All the styling is in one place. And WordPress is just very very good software.

I don’t like leaving content on someone else’s server. As good as the intention to preserve my data may be, if they lose it, or restrict it, I lose, they do not. So I run my own servers. Servers and applications are a joy for me to design and setup – I try to keep maintenance, ongoing attention, and complication at a minimum. That is work. I really do not want to come home after doing this all day, and be forced to perform the same tasks. This structure is simple to set up, easy to backup, doesn’t require any tweaking or jiggering to have run correctly – it can be synced to a second server easily.

Backing up easily – I believe that data that lives in only one place will be lost. Eventually. I run backups to optical media, and never leave data on a single hard drive or single location. I watch people keep photographs on a hard drive, from a digital camera, and ask, have you backed that up? Invariably the answer is “No, I’m going to get to that.” Enterprise level data has been saved by the developer who made a copy of his work. When the backups failed to restore data, he could recover his work.

Ease of setup – I used to compile my own custom kernels to get features out of linux. Now I avoid that. There is virtue in simplicity. The less custom crap the better. There is also much less work over time in the simpler solutions.

WordPress is a simpler solution. It is very good basic structure that can build out over time to a quite extensive site. It allows less work to run my own site, and the content can be exported easily to hosting sites if more bandwidth becomes needed.

—dsm