Schinckel.net

I’ve put the current contents of my template files up on this page. You’ll always be able to find the latest version of my templates there.

Here are some interesting Smarty equivalents of WordPress functions I hadn’t come across before:

• {get_lastpostdate} or {get_lastpostmodified} - returns a timestamp, such as 2005-10-16 07:10:51 that contains the last post date. {get_lastcommentmodified} is identical, but for the last comment.
• {human_time_diff from=n to=n} - similar to a script I wrote about, and implemented. Limited in that it only does days, not any larger unit. Advantage: done by the server, doesn’t ‘flash’ changing text via JavaScript, neater than my Smarty version.
• {get_day_link} - much neater than the version I was using! Generates the URI as described. Also {get_page_link}, {get_year_link}, {get_month_link} and {get_feed_link}.
• {globalvar var=varname value=value} - makes a value a global PHP variable. Very interesting…

After hacking through the source, I finally figured out how to make {relatedstories} work. The trick is that it stores the date in a variable called $relatedstories.

    {relatedstories}
    {if $relatedstories}
      <h2>Related Stories</h2>
      <ul>
      {foreach from=$relatedstories key=key item=story}
        <li> <a href="{get_permalink id=$story->ID}" >
            {$story->post_title}</a>
        </li>
      {/foreach}
      </ul>
    {/if}

I’ve got it set up in my sidebar at the moment. It’s smart enough to figure out when it’s not a single post page, and won’t show then, so you don’t need any fancy extra Smarty Tags to only show in single post view. Oh, and it also sets the variable $relatedstoriesWords, so it’s possible to do something like: <h2 title="{$relatedstoriesWords}">Related Stories</h2> and when you hover over the title, it tells you the words it’s looking for. I’m still working on how to truncate the title. {$story->post_title|truncate} fails dismally. Quite annoying.

Blogsome has implemented RSS feeds in the forums: RSS: click if your RSS syndicator can handle feed: URIs. RSS: an http: link to the feed.

I’ve been playing around with the version of the WP-mu source that’s used on Blogsome’s servers, trying to find the exact point where the bug is that escapes apostrophes and quotes.

Basically, the XMLRPC client contacts the server, and sends the data in. According to the console, the content of the post is actually in a field called description.

Searching through the XMLRPC file I find only five references to the word description. Two of these are in functions to do with posting. Both are basically the same, one is for blogger, the other metaweblog type connections:

1

    $post_content = apply_filters('content_save_pre', $content_struct['description']);

Now, a bit of research showed up that apply_filters is a function that allows plugins and their ilk to access the data before it gets saved to the database. Now, I’m fairly sure it is not a plugin doing this.

I also discovered that it is likely that the update to XMLRPC.php that happened was accompanied by a change to another file, that calls stripslashes(), another WP function. The XMLRPC update was, after all, a fix that removed the ability for XMLRPC calls to run unescaped code. So it makes sense that it escapes stuff.

In the short term, I discovered ecto has the ability to automatically run a script as you post: in the New Post window, make sure Options are showing, and choose the Formatting tab. (Incidentally, if you are only using double-quotes, it seems the Smarten Quotes will help, but it may mess with code).

I use a script that is like this to fix everything up:

1
2
3
4
5
6
7

import sys
data = open(sys.argv[1]).read()

data = data.replace(“'”,“'”)
data = data.replace('“',”“”)

open(sys.argv[1],'w').write(data)

This on its own is not enough - I seemed to have to go into the HTML editing mode before it would work. I think ecto does its own conversion of certain HTML entities to real characters.

This post is a test post to see how it all goes with <pre> tags and the like.

Things I’d like to see in Blogsome:

• The XMLRPC bug fixed. I want to be able to post from ecto again.
• More quicktags. I’ve written some code to enable <abbr> and <acronym> tags, as well as < and > signs.
• The ability to have md5() as a Smarty filter.
• An _RSS _feed from the forums. Not strictly Blogsome, but would be cool. Done!
• Preview in Editing window uses template (or part of template?)
• The GMT Offset bug fixed.

A lot of this stuff should be able to be merged back into the WP/WPµ tree - the XMLRPC bug has been already, for instance. But I understand that the Blogsome team aren’t keen on upgrading the software if it is going to break something.

My script is now up and running, and cross-browser. I’ll leave the Catchpa slightly disabled for the time being so I can test it a bit more on different machines. You’ll also notice a nice little floating toolbar - this is only supposed to appear on the site when a user is logged in, but it seems to be there all of the time at the moment. The script is about 56k, which I think is too big, however I’ve had some issues with the compression utility I was using, so I’ll roll my own solution. It is all in one file again, (easier to manage updating it), and I think the browser caches it, so it should only be slow on the first load. Things I need to do:

• Set it up so the true.gif and false.gif images are preloaded, so there is no delay on the first time a user clicks on a checkbox.
• Have a tag in the template for enabling/disabling checkbox replacement.
• Fix up admin toolbar.

I’m sure there’s probably other stuff I need to do…

I’ve done a bit more work on the script for all of the extras I like to use on my site. Or rather, scripts, as I’ve split it into several smaller scripts, to make it easier for me to debug. I haven’t decided whether it’s faster in little scripts or one big one, just yet. Anyway, to include the mutli-script version, include the following in your head of your HTML document:

1

    <script type="text/javascript" src="http://schinckel.net/images/toolbox.js"></script>

Anyway, the preferred usage has changed, to allow support for Safari (and possibly other KHTML browsers).

Functions:

• Gravatars: usage hasn’t changed. Insert the following into your comments.html file: {capture name=reader}{comment_author_email}{/capture} <div class="gravatar">{$smarty.capture.reader|encode:"hex"}</div>
• Quicktags: those handy little editing buttons to allow easier entry of HTML codes. Since this isn’t supported in Safari, you can use the old method of <!--quicktags-->. I still use this, as it prevents them appearing in Safari.
• Catchpa: not quite ready for prime-time, as it will be coupled with an edit to the form (removing the action attribute, or setting it to " “), and since these scripts don’t yet support IE, there’s little use using it. If you want to see what it looks like, and how it will stop JavaScript enabled Spammers, use <br id="catchpa" />. The old version, using the comment tag, is still supported, but not in Safari/KHTML.
• Resizeable Comment Area: puts buttons up for the reader to extend or reduce the length of the Text Area they can comment into. Not really that useful, since they get a scrollbar anyway. But nice. Use <br id="resize" /> where you want the buttons to appear.
• Comment Preview: my favourite feature. Can be inserted with <br id="commentpreview" /> where you want the comment preview to appear. Optionally, you can put tags in for where the Preview button(<br id="preview" />), and the Live Preview (<br id="livepreview" />) checkbox are to appear.
• Seperate Trackbacks: if you have the code <br id="trackbacklist" /> (or any tag with this id) then any comments that are actually trackbacks will be moved to here. Each Comment class needs to have the following smarty tag inserted in it: {comment_type}. For example:

1

    <li class="{comment_type}" id="comment-{comment_ID}">

If you already have a class, just put a space between the value you already have and the smarty tag.

• Human readable post times: if you place your Post times in a structure like the following, then the times will be changed to a phrase that describes the time of day: Posted <span class="post_time"> at: 12:34pm</span>. Note where the Posted is… all of the content inside the span tags gets eaten up.
• Time Since: you can have your comment times as a certain time “after the fact”, by inserting the following code at the bottom of the comment:

1

    <a href="#comment-{comment_ID}"><span class="timesince" id="{the_time d='U'}-{comment_date d='U'}">on {comment_date} at {comment_time}.</span></a>

The text will all be replaced, but it’s nice to have it there incase someone has JavaScript turned off.

Righto, I think that’s it about it. Still some parts seem to fail on Internet Explorer, but I’ll work on that. Please report any bugs/issues to me, either via email or comments here, so I can try to fix them. That includes anything you notice untoward on this site too, I guess. ;)

I didn’t realize this until the other day, but it’s possible to back up every post you’ve ever made using an offline client, such as the excellent ecto. I use the Mac version of this great program, and to back up every post I’ve ever made is as simple as:

• Find out how many posts you have made.
• Tell ecto to download this many recent posts.
• Press the Refresh button.

The first one is easy: when you first log into your Blogsome blog, you’ll see on the dashboard a panel like:

Blog Stats There are currently 393 posts and 284 comments, contained within 19 categories.

Getting this info to your offline composer might be difficult - each one has different settings. In ecto, choose the Account in the main window (Entries & Drafts), and then go to the ecto→Preferences… menu (keyboard shortcut: Cmd-, ). In the window that appears, choose the Recent Entries tab.

I use the following settings: Store copies of published entries locally, uncheck Retrieve titles and summaries only, and insert the desired number of entries to retrieve. Then, click Save, and press Refresh in the main view. It might take some time if you have a lot of entries, but it’s nice to know you have a backup.

Oh, and if you do regular backups, you can set the value to a reasonable value, like 10 or 20, and make sure you do it every now and then before you’ve posted that many new posts. If you make any edits to old posts, they’ll only get picked up in a large backup like this one, though.

•

If you are using another client, the instructions will be similar, but you may have to search around for a while before you find where to change the number of entries to retrieve. Good luck: happy backup.

I’ve got a bit of JavaScript in my site: Quicktags, Comment Preview, Catchpa and Gravatars, just to name a few of the recent additions. I’ve also got some pretty hairy Smarty Code thrown in there too. Some of it would be better off to be replaced by JavaScript. The two main examples of this are the Time Since code (eg: 22 hours, 34 minutes after the fact), and the _Human Time _code (Posted late at night). I’ve actually rewritten pretty much all of this code, and packaged it all up into one JavaScript, so I can just let other people include one line of code, with some others setting up what features they want, rather than having to wade through the code and find where to add bits. At the moment, most of it is quite functional, but would still require the use of a whole bunch of inline scripting. I’m working to replace this with functions that automatically run after the page has loaded (or, perhaps even better, when the main page has loaded, but before it displays?). So, for instance, you would just have the following code in your main page, inside the <head> section: <script type="text/javascript" src="http://schinckel.net/images/blogsome.jpg"><script> And, then in the templates, include a block of text that looks like: <div class="options" style="display:none;"> gravatar preview quicktags </div> You can have different features on different templates: the one above would make sense on a comments page, but not on others, for example. There will be robust error checking as to validity of particular features and their applicability on a particular page, but only including features you actually plan to use will make the page load faster. This ultimately should make the page load faster than with all of the inline code, and calls to several external javascripts. I think browsers will cache the blogsome.jpg file (it’s really a .js file, but don’t tell anyone), so the initial load time will be reduced on successive page loads. It will also mean I can add or improve features, and fix bugs. The tricky part is turning out to be catering for different layouts: the gravatar part was easy: the only code a user needs to put into their blog is the simple {capture name=reader}{comment_author_email}{/capture} <div class="gravatar">{$smarty.capture.reader|encode:"hex"}</div> Where they want the gravatar to appear, and it will work. Setting up for the Catchpa, which is pretty simple, turned out to be a little sticky. It all depends on how people’s templates are set up: what the structure of their form looks like. It might be easier to have them insert some HTML code, and then look for that. It makes it a little more work for the user, but more reliable.