Apache MultiViews automatically appends .html, but I don’t want it to

Hat-tip to Abdel-Karim Mardini for reminding me which Apache directive is poison. It’s Options MultiViews.

A client reported that WordPress pages weren’t working. For example, example.com/press/ was showing a 404, even though WordPress had a page with that permalink. What was strange was that example.com/press was showing a very old version of the correct page, which was stored on the file system as press.html.

I checked the code on my local server and looked through the apache log files. No help. I deleted all the directives from .htaccess. It was still happening. But I vaguely remembered that Apache “automagically” appends .html to certain URLs. Google was very little help, mostly showing me how to write apache rewrite rules. But since I had disabled .htaccess, I knew that wasn’t it.

I finally found Abdel-Karim’s summary, and sure enough, appending this to my .htaccess file, worked:

Options -MultiViews

Here’s hoping I remember to check my blog next time, before spending hours staring at log files and useless search results.

Posted in Uncategorized | Leave a comment

CakePHP logoutRedirect is not the same as loginAction

If you go through the CakePHP Auth example tutorial, you’ll end up with two (not three) configuration settings in your AppController > components > Auth settings. They will look like this:

public $components = array(
        'Auth' => array(
            'loginRedirect' => array('controller' => 'posts', 'action' => 'index'),
            'logoutRedirect' => array('controller' => 'pages', 'action' => 'display', 'home')

I unconsciously made the incorrect assumption that “logoutRedirect” would always take you to the login page. You log out.

You get redirected to the login page. But when I put my carefully crafted login page at pages/home. Yet when I visited my site without a proper cookie, I wasn’t redirected to pages/home. I was redirected to users/login. Where the heck was that coming from?

Turns out there is another AppController > components > Auth setting that specifies where the login action is found. When you add it to your other components, it will look like this:

public $components = array(
        'Auth' => array(
            'loginAction' => array('controller' => 'pages', 'action' => 'display', 'home'),
            'loginRedirect' => array('controller' => 'posts', 'action' => 'index'), 
            'logoutRedirect' => array('controller' => 'pages', 'action' => 'display', 'home') ) );

It seems that logoutRedirect is only used for where to go, immediately after logging out.

I wrote this post because a coworker had made the exact same assumption and mistake as I had.


Posted in CakePHP | Leave a comment

CakePHP Auth->allow only works on actions, not controllers

If you follow the CakePHP documentation on Authentication, you might end up with this line of code in your AppController.php file, in the beforeFilter() method.

$this->Auth->allow('view', 'index');

… And that’s fine for demo purposes. But that actually allows all view() and index() actions, on every controller in your application.

That’s not likely what you want. You will need to move that line of code out of the global AppController.php file, and put it in each SpecificWhateversController.php file, allowing whatever the specific actions you want to allow to users who have not logged in.

Posted in CakePHP | Leave a comment

WordPress “recent posts” file to be included on another page

I have a client who finally asked for something I told him we could easily do. He wanted the recent posts from their blog sub-site to be listed on a sidebar on their main site. We wanted a dynamic list of the most recent headlines, linked to the content.

Since we already spent the budget on “bigger fish,” Before I muddled my way through the WordPress templates, I did a quick web search to see if someone had already written my code for me. Sure enough, David Walsh, a respected developer whose work I already follow, had the answer. I’ll send you to his blog for the code.

Create a “Recent Posts” Module Outside of WordPress

Thanks, Mr. Walsh. Keep up the good work.

Posted in Web programming, WordPress | Leave a comment

WordPress replaces your menu with a single button

Actually, it’s not WordPress per se, but the TwentyTwelve theme. If you look at your beautiful site or blog on a small device, your carefully structured menus will be reduced to a one-dimensional abomination labeled “Menu.”

Wordpress reduces your menu to this

WordPress reduces your menu to this

Well-intentioned designers created this

Well-intentioned designers created this

In looking for a fix, I discovered that it was created by well-meaning theme developers. They think that if you’re viewing a site on a small screen, a larger menu is unusable, so they’re taking the decision out of your hands and “fixing” it for you, with no way for you to opt out.

Thanks, but no thanks.

Another commenter suggested it was made this way because “hover” states don’t work on touch-screen phones. Nice thought, except the decision to go one-dimensional isn’t based on touch input, it’s based on screen width. Plus, you can’t have a top-level navigation item in WordPress that isn’t a link — that is only a hover. So, again, nice thought, but no thanks.

What my client has found is that, although we offer a mobile site, some people like to see the regular, full site, and zoom in to what they are looking for. I’m not sure I agree, but who am I to argue? And who is WordPress to dictate? (Can you tell it’s late and I’ve spent too much time trying to track this “feature” down?)

Enough already. Here’s the fix.

Open the CSS file for your theme. Search for this phrase:

@media screen and (min-width: 600px) {

Change the 600px to 6px.

You’re done.

Posted in WordPress | Leave a comment

Chrome shrinks images in table cells

Chrome shrinks images in table cells! That was my accusation while working on a WordPress site. The images were correct in Firefox, but in Chrome, they got shrunk down to thumbnail size.

Firefox provided the desired effect

Firefox provides the desired effect

table images too small

Chrome shrinks the images in the table cell down to thumbnail size

I checked the styles for widths, table-layout, anything that might let Chrome think it was okay to shrink the image. After much research I found the culprit. It’s max-width:100%. Apparently Chrome interprets the rule differently from Firefox. It assumes the image can freely be shrunk, and with a long string of text in the cell next door, it squeezes the images.

The culprit

The culprit

The fix

The fix

I understand why the WordPress theme designer wants to set a max-width on images, but for Chrome, and in table cells, it’s more trouble than it’s worth. So I created a new style declaration in my theme’s stylesheet:

.entry-content td img {
    max-width: none; 

Posted in CSS, WordPress | 21 Comments

WordPress ate My HTML Too

The WordPress team admits that a common complaint is “WordPress ate my html.” Their latest “fix” to this issue is to relabel the HTML tab as “Text.” I’m all for truth in labeling, but it seems like a lazy fix.

I spent many days pondering how best to rebuild an existing web site in WordPress as simply as possible — hopefully pasting HTML from the existing web site. The HTML tab (now “Text” tab) didn’t work.  It added BR tags unnecessarily, then converted them to P tags if you saved and reopened the page in the admin section.

Add the HTML source button to the WordPress toolbarAt some point I stumbled on an implementation of TinyMCE that had an HTML button. It opened a popup and allowed me to paste HTML, without messing it up. Hooray!

To add the HTML button to your WordPress admin screens, find the functions.php file in your WordPress theme. Add the following code to the end of the file:

function my_mce_buttons_2($buttons) { 
  * Add in a core button that's disabled by default
  $buttons[] = 'code';
  return $buttons;
add_filter('mce_buttons_2', 'my_mce_buttons_2');

It worked almost perfectly for my conversion job. I found out that if you’re pasting HTML comments, WordPress still converts the closing comment from –> to –> (notice that even in this post, WordPress has converted my dash-dash to an en-dash, which breaks the comments). The best advice I found was to let WordPress do its thing and then convert them back.

Save this code to a file called dont_break_html_comments.php — save it in your plugins directory. Then go to the plugins  panel and enable it.

Plugin Name: Don't break HTML comments
Description: HTML comments in pages get converted to en-dashes, resulting in missing content on those pages.
add_filter( 'the_title', 'un_en_dash' , 50 );
add_filter( 'the_content', 'un_en_dash' , 50 );
add_filter( 'the_excerpt', 'un_en_dash' , 50 );
add_filter( 'comment_text', 'un_en_dash' , 50 );
add_filter( 'list_cats', 'un_en_dash' , 50 );

function un_en_dash( $text ) {
  $content = str_replace( '–>' , '-->' , $text );
  return $content;

Understand that pasting your HTML is really a one-way operation. Once the pasted HTML is in place, leave it alone. If you must make changes, make them using the HTML editor. The visual editor (and new “Text” editor) could still change the underlying HTML if you use them. Luckily, for me, that was not an issue.

Posted in Webmastering | Leave a comment