Releases FAQ ­ Textpattern CMS

Releases FAQ: Full Listing

My plugin's "Extension" sub-tab has gone missing!


After an upgrade to 4.0.6, some admin-side plugins have their “Extension” sub-tab disappear from view, and trying to access the URL directly displays the message, “Restricted Area”.


  • You need to install an updated version of the plugin or…
  • The plugin in question needs to be updated.Contact the plugin author to remind them.

Below is a list of plugins with known problems, and what to do for each.

Temporary Fix

While waiting for the plugin author to update, you can fix this problem on your own site yourself.

Edit the plugin and look for the bit of code that looks like:

if (@txpinterface == 'admin') {
	register_tab("extensions", "event", "tab name");

For each occurence of register_tab, we need to insert an extra line of code:

if (@txpinterface == 'admin') {
	add_privs('event', '1'); // this line's "event" should match the one used by register_tab
	register_tab("extensions", "event", "tab name");


Why do all my links point to "https" instead of "http" with IIS?

It’s a bug in the auto-detection of whether SSL is used on the connection or not. You can however override the autodetection code by alway forcing the type of protocol (dssl or not) that you prefer. This is done by adding the following line to config.php:

define('PROTOCOL', 'http://');

Similarly if you wanted to force textpattern to generate ssl-urls, you could replace http with https in the above line.

Comment preferences are missing


I have my admin preferences set to allow comments, but the Comments section of the preferences does not show up.


This is a bug affecting all past and present stable versions. The bug is actually quite old, undetected for some time. This is likely to do with the fact that past versions of MySQL are more forgiving, and people are updating to the newer, more strict (correct) versions.

It has been fixed in the latest development version of Textpattern, and so will be resolved in the next stable release.

The problem is simple enough to correct. For version 4.0.4, make sure line 89 of your textpattern/include/txp_prefs.php file matches.

It is always recommended that you update to use the latest stable version of Textpattern, as it includes many bug fixes (some of them security-related).

Why does Textile add span class="caps"?


Textile adds <span class="caps">...</span> tags around capital letters. How do I stop this?


Textile wraps strings of 3 or more capital letters in a special span class, like this:

<span class="caps">IBM</span>

This is to allow acronyms, initialisms and the like to be uniquely styled. Many typographic guides recommend using additional letter spacing in strings of capitals. Textile, being a typographically rich markup syntax, is intended to make such things possible.

Textpattern includes a CSS rule for additional caps letter spacing in its default stylesheet, something like this:

	letter-spacing: 0.1em;

If you don’t want special letter spacing for captials, simply remove or comment out that rule from your stylesheet. Once it’s gone, the span tags will have no effect.

Clean URL Test Failed


The pre-flight check says “Clean URL test failed.” What does this mean?


“Clean” URLs work out-of-the-box on most servers, but not all.

If you’ve selected a Clean URL scheme, the Textpattern diagnostic page will try to determine whether they are working correctly on your server.

Clean URL test failed means they’re either not currently working or your server doesn’t support the actual test procedure; if your clean urls on your site still actually work, you can ignore this message. If the clean urls on your site are not working and you’re seeing that message in your pre-flight check, it means one of three things:

1. Your “Site URL” setting is incorrect, or the page at that address is not managed by this copy of Textpattern; or

2. Your server requires some changes to .htaccess in order to make clean URLs work; or

3. Your server doesn’t support clean URLs at all.

The Clean URL test attempts to fetch a page from the web address specified in the “Site URL” preference in order to check that all clean URL parameters are working correctly. If that URL is a different site, or has been replaced with a static page or similar, the test will fail.

Modifying .htaccess is a trial-and-error process. Some hosting companies might already have a working Textpattern .htaccess, so check their technical support resources. Otherwise, you’ll find instructions in this FAQ for editing .htaccess, and for switching to messy URLs if all else fails.

file_download_* shows same url multiple times

Due to a bug in Textpattern 4.0.4, when you have multiple download-links to different files generated by file_download, file_download_link, file_download_list, the first link will show the correct link, however all later download links will point to the first download as well, instead of the respective other downloads.

To fix this issue you need to replace the file textpattern/publish/taghandlers.php with the following version:

textpattern/publish/taghandlers.php [1968]

Once you’ve replaced the file, you can check in high level diagnostics by confirming that it has this line:

/publish/taghandlers.php: unknown (42f621ba6099a81dcff8edf3c96c4adb)

You will also receive a warning that some textpattern-files have been modified. This is correct, as we actually did modify a textpattern file.

Comment spam blacklist false positives


I’m being incorrectly blacklisted when trying to post a comment on my site.
Users report blacklist messages when trying to post comments.


A bug in Textpattern 4.0.4 can lead to false positives on comment spam blacklist checks in some circumstances.

The problem only affects servers and hosting companies that use a wildcard DNS record for the server hostname itself.

To fix the problem, update to the latest stable version of Textpattern (currently, v.4.0.5).

MySQL table errors


I get a mysql_table_errors message in the pre-flight check on my diagnostics page.
mysql_table_errors: txp_lang: error: Size of indexfile is: 1024 Should be: 53248, txp_lang: error: Corrupt


This and similar errors mean one or more of your Textpattern database tables have been damaged. Usually a server crash or MySQL bug is the cause.

See this FAQ for more information, including pointers to instructions for repairing tables.

CSS sometimes fails to load


Sometimes when I refresh a page, the CSS stylesheet loads only partially or takes a long time.


A bug in some versions of mod_deflate — a compression add-on for Apache used on some shared hosting servers — can sometimes cause CSS caching to fail.

Textpattern’s caching feature is only enabled in Live mode, so temporarily set your production status preference to Testing to disable it, and see if the problem still occurs. If that stops the problem, the mod_deflate bug is probably the culprit. You’ll need to turn off caching to fix it (go to Admin > Preferences > Advanced, and set Send “Last-Modified” header? to No). You can switch production status back to Live once you’ve done this.

We’ve confirmed the problem occurs on at least one of Textdrive’s servers.

Warning: page template does not contain an article tag


I get a warning message in Testing mode that says, “Page template … does not contain a txp:article tag”


Textpattern is warning you that your page template doesn’t contain a <txp:article /> tag.

The <txp:article /> tag is the main Textpattern tag responsible for displaying page content. If it’s not present, your page might display the wrong content, or no content at all.

The message is a warning only. It will not be displayed in Live mode. If everything is working correctly, you can safely ignore it.

Comment input form changes

Textpattern 4.0.4 includes improvements to some of the comment input form code. Most of the changes are internal improvements, but there are minor changes to behaviour in two cases, listed below.

None of these changes should affect the default template code distributed with Textpattern. In most cases you won’t notice any differences. There’s no need to change anything or understand the changes unless something is broken.

If you have created your own custom forms for displaying and submitting comments, you might notice two differences:

1. The position of the automatic comment preview

In older releases, the <txp:comments /> tag would automatically display a preview of the submitted comment, unless a <txp:comments_preview /> tag is explicitly used to position the preview elsewhere on a page.

In Textpattern 4.0.4, the automatic preview is displayed by the <txp:comments_form /> tag instead. Depending on your page layout, this might mean that the preview is displayed at the bottom of the article instead of the top. (A link anchor is used to position the user’s browser at the correct place on the page, wherever that might be).

The end result and user experience should be effectively the same in almost all cases.

2. The <txp:comments_form /> tag behavior

The preview attribute of the comments_form tag is no longer necessary. If your template code includes this attribute, you’ll see a warning message.

In older releases, the comments_form tag required some complex behaviour during a comment preview. In the new release, it is much simpler:

  • If the <txp:comments_form /> tag is used by itself, without a <txp:comments_preview /> tag, it will automatically display a preview of the submitted comment just before the comment input form.
  • If a <txp:comments_preview /> tag is included in your template or form code prior to the <txp:comments_form /> tag, comments_form will not display an automatic preview.
  • If your template or form code includes a <txp:comments_preview /> tag after the <txp:comments_form /> tag, both tags will display a preview of the submitted comment. You can prevent comments_form from displaying a duplicate using its show_preview attribute:

<txp:comments_form show_preview=0 />

Similarly, show_preview=1 will force the comments_form tag to always display an automatic preview, regardless of whether or not you’ve also used a comments_preview tag.

Some plugins stopped working


Some admin-side plugins stopped working when I upgraded to 4.0.4


Some XHTML elements and CSS IDs have changed in the Textpattern administration interface in version 4.0.4. The new XHTML is much cleaner and easier to manipulate using Javascript.

However, some older plugins use Javascript DOM code that relies on specific XHTML structure or IDs, particularly on the content > write page. These plugins will still run, but won’t display user interface elements correctly on administration pages.

The solution is for plugin developers to update their code. The necessary information is available in the plugin forum, including examples. The new code in 4.0.4 makes it much easier to add UI elements to admin pages.

Warning: Unknown tag attribute


Warning: unknown_attribute …


Textpattern 4.0.4 includes stricter error checking for template tags. Amongst the improvements, it will now produce a warning if you use a tag with an attribute that is unknown.

Warnings are only shown in Testing and Debug modes, they won’t be displayed when your site is set to Live.

In some cases, tag attributes might have changed slightly between Textpattern versions. This tag might be used in some comments_display forms from 4.0.3 and earlier:

<txp:comments_form preview="1" />

The comments_form preview attribute is no longer needed or supported in Textpattern 4.0.4. You can safely remove it.

For warnings about attributes on other tags, please check the tag documentation.

Warning: Raw PHP tags are deprecated


Warning: raw_php_deprecated


As of Textpattern 4.0.4, “raw” PHP tags (like <?php ... ?>) are officially deprecated for security reasons1. You should use Textpattern’s built-in <txp:php> ... </txp:php> tags instead. Code in raw PHP tags can still be used, but Textpattern will always display a warning message when in Testing or Debug mode.

On fresh installations, raw PHP is disabled by default. You can turn it on via the allow_raw_php_scripting setting in Advanced Preferences.

On sites that have been upgraded from previous versions of Textpattern, allow_raw_php_scripting is enabled by default. We recommend you disable it, and use Textpattern’s PHP tags instead.

1 There are no known issues that could allow a remote attacker to execute or compromise PHP code. PHP code can only be inserted or modified by authorized Textpattern administration users. The security problem is that it’s not possible to have fine-grained permission control over code in <?php ... ?> tags. <txp:php> ... </txp:php> tags, on the other hand, can be enabled and disabled separately for different user levels and in different contexts (template or article).

Comments no longer work properly


Comments stopped working after I upgraded to 4.0.3


Comments work fine in 4.0.3 if you’re using the standard comment form tags.

It seems some users have replaced their comment input form with hard-coded <input ... /> tags. This is incompatible with the new comment spam protection code in 4.0.3. See this forum thread for details.

The safest way to fix the problem is to replace your comment_form with the default. You can change the HTML markup in that form, but the <txp:comment... /> tags must be present.

See here for a brief explanation of the main comment tags and forms.

Older and Newer tags no longer work

QUESTION:<txp:older> and <txp:newer> sometimes don’t work in Textpattern 4.0.3


This problem appears to be caused by the rss_thumbpop plugin.

Why does the comment form prevent validating as XHTML 1.x strict?

This bug was introduced when of us developers was unaware of the necessities of strict validation w.r.t. forms. Unfortunately it was only caught after the release. This has since been fixed and the fix will be included in the next release.

This issue is being discussed in the forum in the following topic, which also offers advice on how to temporarily fix this, should strict validation be important to you.

Some pages are suddenly missing CSS-styling after the update?

There’s a little bug in 4.0.3 that appears (only) when production mode is set to testing or debug and you are using <txp:css n="nameofstyle" /> (or stylesheet links that look like css.php?n=nameofstyle). Pages referring in such a way to a stylesheet may appear unstyled and the stylesheet may return an error-message.

Easy Solution: Please set your production mode to live (which is always recommended for production sites anyhow) and you won’t experience the bug.

(Note: If for some reason you have the need to fix this bug in testing/debug mode as well, you can follow the instructions in this forum thread.)

Where did the error-messages for comments go? How can I style them?

4.0.3 brings improved handling of required fields and errors during commenting. There is a new tag for your comments-form called <txp:comments_error class="comments_error" break="br" wraptag="div" /> which will list all the error-messages related to the comment. This can include Textpattern’s own messages for missing required fields (like e-mails, or comment body) or messages from comment-plugins. The Update-Procedure should add this tag to your default comments_form, but if you are using additional forms or want to customize the output, you can addchange it yourself. Additionally there is also a new tag: <txp:if_comments_error>.

Styling can be achieved via CSS. You can also highlight the faulty input-fields themselves, because they will also get an additional class assigned called “comments_error”, when the user needs to re-check that field. So simple example rules would be:

.comments_error { background-color: #ffa }
div.comments_error { border: 1px solid #cc8; padding : 0.3em;}

This will give all comments_error related fields a slightly yellow background and will additionally emphasize the div with the error-message through a border.

How do I turn off register_globals?


The diagnostic page tells me to turn off PHP’s register_globals setting. How?


This depends on the way your server is configured.

On many hosts, you can edit your .htaccess file, and remove the # character from this line:

#php_value register_globals 0 it looks like this:

php_value register_globals 0

On some servers, this will cause a 500 Internal Server Error. If this happens, replace the # character at the beginning of that line, and ask your hosting company for advice.

if_comments, comments_invite changes


<txp:if_comments> is broken
<txp:comments_invite /> is broken


The behaviour of the <txp:if_comments>...</txp:if_comments> conditional has changed in Textpattern 4.0.2. Under normal circumstances we don’t change the existing behaviour of tags in minor releases, but in this case the old behaviour wasn’t as originally intended, and the tag was almost useless as a result.

Previously, the default template contained code like this, for displaying the comment invitation link:

<txp:if_comments><p><txp:comments_invite /></p></txp:if_comments>

In 4.0.2, the meaning of if_comments has changed from “if comments are turned on”, to “if at least one comment exists for this article”.

To achieve the same result with Textpattern 4.0.2 or higher, use the following code:

<txp:comments_invite wraptag="p" />

The default template included in 4.0.2 has been updated, so if you’re installing from scratch with 4.0.2 or higher you don’t need to change anything.

If you’re using a derivative of the default template that originated with version 4.0.1 or earlier, you’ll need to change that particular fragment of code as shown above.