Code / Appnel Solutions 

Reset

“The cobbler’s children have no shoes” is an old saying that applies to Appnel Solutions and appnel.com.

I’ve been meaning to do a lot with this site for a long time, but have always been short on time working with clients and staying involved in the MT community to get it done. The list was really piling up to the point of paralysis. The release of MT4 was the final straw though.

I decided to throw down the gauntlet and finally do a complete overhaul.

I know there are developer luminaries that talk about resisting the urge to do so, but I get the feeling that advice assumes you have been caring for your site/application all along. Still it’s not a good idea, because the likelihood of failure is indeed high. Nevertheless I did and things seem pretty good so far. (Encouragement is appreciated.)

Besides the new look (a slight modification of Derek Powazek’s DepoClean template set), I’ve moved much of the content from index templates and entries to pages, simplified the download of plugins and started doing a lot of content pruning and revision.

I’ve also started to blog again. I’ve missed it a great deal and have wanted to get back in to it, but something kept stopping me. It final dawned on me that I was trying to blog about things that aren’t my strengths or inclinations. Blogging needs to be easy and that doesn’t just go to the tool. And while I haven’t been blogging, I have been writing some pretty lengthy and (seemingly) useful email messages that never made it past select inboxes. I’ve resolved to do more blogging on what comes naturally to me. Here it will be a lot about MT development.

There still quite a bit to do and sure some things that are broken (bug reports welcome), but I think I’ve reached a point to cut it over. So here it is. Let me know what you think.

Tips For Customizing Templates With Comment Forms In MT4

A common issue I see come up with MT users customizing their templates is getting the comment form to work properly when registration is required or an option. Unfortunately authentication (logging in) and dynamic display is relatively more involved then simply laying out content in pages.

Here are some of the common mistakes I've seen users make:

Forgetting to load the blog's JavaScript library.

Be sure you are including (loading) the blog's MT javascript files in the page head of all your entry and page templates that have a comment form. By default this file is mt.js and is generated by an Index Template called JavaScript in MT4.

Modified or missing tag IDs.

Be sure to keep the same HTML/CSS ids. The JavaScript library MT generated for each blog powers the display of the comment form and remembering a users info. I'm not going to list them all here because there are quite a few. The default comment form markup can be found in the file named comment_form.mtml in the mt4/default_templates directory.

Missing hidden form variables.

MT comment forms need to pieces of information passed as hidden field variables:

The static field tell the MT comments script it is receiving its content from a static page rather then a dynamic script. (This is mostly a legacy issue from previous versions of MT.) The other is the system ID for the entry or page the comment is to be associated. The __lang (yeah that double underscore prefix is kind of ugly and seemingly unnecessary) is new to MT4 templates and (remarkably) define what language to use with its system messages. It's not clear to me why MT can't look this up rather then having us pass it. For now, just do it.

Forgetting to run individualArchivesOnLoad once the page has loaded.

Be sure your entry and page templates are running individualArchivesOnLoad(commenter_name) once the body is loaded. The MT default template will generate something like this:

I structure my custom templates differently and prefer to handle this differently by placing this piece of scripting in my page head:

It's a bit more involved, but I have the option of adding other routines to run after loadings and I avoid the conditional logic to generate the body tag like the MT4 default template.

Make sure you don't run individualArchivesOnLoad too soon. If your comment form elements haven't loaded before the browser runs this function you will see a JavaScript error like "document.body had no properties."

Modified form button names.

MT uses the names of the Post, Previews and (now in MT4) Reply buttons to know what mode to process the comment being submitted. Some users will understandably want to rename these buttons and will change the value (the label) AND the name. You need to keep those name or make addition arrangements to submit this information with each comment using another hidden variable or a javascript.

Final word

I hope this will be helpful to those who are under taking such a task. This is not a complete list. A related area of problems is in getting your authentication setup and running properly. MT4 introduced a lot of changes in this area -- a subject worthy of a separate post entirely.

Customizing your templates and getting them to work with the registration capabilities MT supports is doable -- its just requires a bit of extra patience and know-how.

Search Throttling and Shared Hosting Environments

Recent on the mt-dev mailing list, Su asked “Does ThrottleSeconds even work in 3.35?” He noted that he was experiencing a lot of “search requests coming in” in 5 second intervals. He set the ThrottleSeconds directive in the systems configuration file, but it wasn’t stopping the bogus search requests.

Not being about to turn down forensic challenges involving the MT code and since we all owe Su a lot for his community efforts I dug in and replied:

It looks like there are two places were the search throttle that could die silently that you’ll want to check into.

1) if DB_File is not installed on that system.

This module is part of the standard Perl distribution since forever from what I recall so its unlikely. I suppose it’s possible that the underlying compiled libraries got hosed that this may make it fail, but I think its less likely then…

2) Your system cannot write to the (configured?) temp directory.

For reasons in which I am unsure, the search throttle uses good old BerkeleyDB regardless of the database you are using. In order to do that it must write a file. With no file path to work with it defaults to the little used configuration directive TempDir which defines the system temporary files directory. When (typically) undefined it defaults to the unix standard /tmp/. You would have to test if you can write to that directory. I have experienced systems where a script cannot write to a directory outside of the web root. The default /tmp/ directory would certainly be outside of a web root in which case mt-search would not be able to write any throttling information and would let the search continue without a warning, error or even a pause.

BTW: One other flaw that occurred to me (though unrelated to your problem) as I looked into this was that you would periodically lose all your throttle information as anything in /tmp/ is subject to periodic deletion. How often depends on the system admin.

[Read more →]

Template Context Variables Now Stashed In Lowercase

The following is a slightly edited fun “rant” I posted to the mt-dev list while working on my existing plugins and MT4 during its beta a couple of months ago.

While my “rant” was meant to be a bit of fun that let me blow off some steam there are two points worth noting:

• Beginning with MT4, template variables are stored in lowercase and are case insensitive.
• This is a classic case of why object-oriented (OO) principles is necessary in sophisticated applications over its lifecyle. Actually this is more of an example of how not following OO principles will sooner or later cause you grief. So the next time you are wondering why I’m being a grouch about something not following OO principles, see this post.

[Read more →]

On Variable Scope

This post contains a lightly edited reply of mine that was posted to the mt-dev mailing list over a year ago. I thought I would pull it from the archives and highlight it again since scope is an important concern of developers when developing code that will run in persistent FastCGI.

Mark Carey wrote:

What is the best way to "limit the scope" of variables? And while I think I know what objects and methods (subroutines/functions?), I am less clear about what are Classes and "class data" and how to deal with the scope issues there.

To which I responded:

Scoping is a bit of a broad topic. Hopefully this example should help with the basics though. Take this class (in Perl this is a package that conforms to a few object-oriented programming principles):

In this example module (class) anything store in $class_data_persists will be shared by any object of Some::Class. So for instance.

Notice that $x and $y are objects of class Some::Class and that I stored the value 'hello world!' in $x and yet $y knew about it to output it when called. Since a persistent environment like FastCGI loads Some::Class once and leaves it in memory the value 'hello world!' will remain until the class is reloaded or overwritten with a new value. This simple value is not damaging, however it can easily be abused by storing large amount of data that consumes memory perhaps with data that has become "stale" (its been updated in the database). The worst case is when the class data keeps growing -- this is what is referred to as a memory leak. As the application runs it eats up more and more memory until the server comes to a crawl and finally crashes. This is a big issue in C programming, but less so in scripting languages like Perl which clean up memory that has gone out of scope. Perl still lets you leave variables and data in some long term or persistent scope which is what we are discussing here.

[Read more →]

Editable Dates and the authored_on Field

A defining trait of a blog is its chronological order. In the past this crucial date and time was stored in the created_on field whose default was the first time a post was saved to the database.

MT has permitted authors to change this time and date (timestamp) to enabled scheduling a post for future publication or post dating a post when migrated. When changed the created_on fields in the database would be changed. The problem is that the sometimes useful information of knowing when a post was entered into the database was lost.

MT4 introduced a third timestamp field that joins created_on and modified_on in entries and the newly added pages. Now when an author changes the date of a post or page it’s reflected in the authored_on field.

While this change is transparent to users, some older plugins that worked in MT3 will seem to ignore these changes and list entries in “the wrong order.” Many pre-MT4 plugins are sorting on, and even selecting by, the created_on field which will cannot be edited through the MT interface.

Just something to keep in the back of your mind going forward.