Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • @ahomeniuk

    One case of this (probably the one you’re finding) is a result of an invalid rewrite rule in the .htaccess file for the site.

    If you have access to FTP to the site, fine the file .htaccess in the top level directory of your site. First make a backup copy. Then edit it with a text editor (not a word processor — plain text characters only) and comment out all the lines between # Begin W3TC and # End W3TC by adding the # character at the beginning. There may be multiple sections of W3TC directives. Upload the new version of the .htaccess file, and this should get your site working again.

    It would be very helpful, if after you get the site back up you could write back — I believe there is a fix for this and it would be great if you had a few minutes to try it out. I can provide more information then.

    Tom

    I have several installations that use Contact Form 7 and W3 Total Cache working fine together and didn’t have to do anything special.

    What’s the symptom? What’s your environment? Have you tried the W3TC debug settings? Which versions of WP and the plugins?

    Tom

    After further investigation, I believe this error is most likely on a shared host — one of the RewriteCond statements specifies the full filesystem path to a certain file, and it seems unlikely that a shared hosting apache server would have full access to the filesystem path.

    I have reported this as a bug to Frederick Townes.

    Tom

    I am having this problem on one of the sites I am managing, not others.

    how can we even go to the support tab of the plugin when the whole site is in 403

    Answer: the default configuration is to not cache for logged in users. I have one browser where I am logged in, and another where I am not for testing.

    I will submit a bug. In my case, it seems possible that the cause is because the site is installed in a subdirectory of the DocumentRoot of the site (e.g. ../htdocs/blog) so site_url and home_url are different. I am working on diagnosing it. I am pretty sure it’s not simply a permissions problem — I think a .htaccess is getting in the way.

    FYI, I was able to successfully restore site functionality by disabling the plugin.

    W3 Total Cache works great on several other sites.

    Hi Frederick —

    (Sorry to resurrect an old thread, but I think I am having the same problem as described here) — style.css background images from my theme don’t have quotes and are not getting picked up and served from the CDN (Cloudfront).

    I am using WP3.0.1 and WPTC 0.9.1.3

    Any progress on this issue? (Minor of course, I am just trying to get an A in YSlow and PageSpeed ๐Ÿ™‚

    Tom

    I was seeing what appears to be the same problem. Currently running WP 2.7.1 on Ubuntu (was going to upgrade but ran into this issue first).

    I was writing down how to reproduce the problem, but now I can’t … so is this a possible solution?

    Steps:

    1. rm -rf askismet from the plugins directory
    2. WP Admin > Plugins > Plugin Browser/Installer
    3. Search for Akismet and install using FTP installer
    4. Installation succeeds: directory created, same permissions as others in plugins, everything looks good
    5. Activate. It works.

    So I am pretty sure this didn’t work, and wp-settings.php was failing on the include_once function on line 473 … which doesn’t make sense since this is only done after a check that the file exists and so on. Bizarre.

    Call me crazy, but I think there’s something up with WordPress (or perhaps the Backup plugin). I am working on moving my WP database to a new domain (on the same server). I took a backup of the database with the DB Backup plugin and created a new database (using the same defaults as the current database).

    Without other changes, a page having special characters (in my case left and right curly quotes) that displayed fine on my current domain displays on the new domain the same special characters as you are talking about in your posts.

    Same mysql, same version of wordpress, same character set variables (show variables), same settings in wp-config.php, doesn’t matter what theme (characters show up right in admin on old, wrong in new).

    I am a little perplexed, but in my case there are only a few cases (curly quotes that came in from copy/paste) so I’ll just manually fix them. But something is getting messed up, presumably either in the dump or load.

    Tom

    Thread Starter Tom Harrison

    (@fivepercent)

    Ok, so I sorted out my remaining problem with permalinks and subdirectories. Adding the AllowOverride Options in a <Directory /home/user/blog> section was the trick.

    The reason I continued to have problems was that the virtual host configuration was in conflict. It has a <Directory /home/user> section that specified AllowOverride none — this directive prevents the .htaccess file in the blog subdirectory from ever getting evaluated.

    Since I have access to the virtual host config, I was able to specify everything in one place, and eliminated the .htaccess file (as recommended by Apache documentation, for performance reasons). Here is the VirtualHost snippet, which accomplishes the same thing as the .htaccess file:

    <VirtualHost *:80>
        DocumentRoot /home/user/
        ServerName mydomain.com
        ServerAlias www.mydomain.com
    
        <Directory "/home/user">
          Options FollowSymLinks
          AllowOverride none
          Order allow,deny
          Allow from all
        </Directory>
    
        <Directory "/home/user/blog">
          RewriteEngine On
          RewriteBase /blog/
          RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule . index.php [L]
    
          Options FollowSymLinks
          Order allow,deny
          Allow from all
        </Directory>
    </VirtualHost>

    Note that the RewriteRule specifies . index.php, not . /blog/index.php since it is in the context of the <Directory /home/user/blog> already.

    (There are other things in the virtual host, but these are the relevant ones to my situation. And no, my user is not really user ๐Ÿ™‚

    Thanks again, samboll — I owe my eternal gratitude for your help!

    Thread Starter Tom Harrison

    (@fivepercent)

    @samboll

    This gets me closer — I can load the permalink version of the pages, the home page, and the page in the Apache DocumentRoot — thanks! But now it appears that Apache is not finding actual files and directories, so images, css, and wp-admin don’t work.

    I’ll read the Apache manual to figure out what’s going on, but if you have any further advice or thoughts, I would be most grateful.

    I’ll re-post if I find a solution.

    My /home/user/blog/.htaccess now looks like

    Options +FollowSymLinks
    <Directory /home/user/blog>
       AllowOverride Options
    </Directory>
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /blog/
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /blog/index.php [L]
    </IfModule>
    
    # END WordPress

    Thanks!!!

    I finally sorted out my “Unable to locate WordPress Plugin directory” problem.

    In my case, the issues was that the FTP server (vsFTP) was configured to prevent write operations (such as the creation of a temporary directory) used by the upgrader.

    I logged in as the user whose home directory was where WP is installed (in ~/wordpress) — all was well. No other special configurations were needed.

    I attempted to use the 2.1.2 plugin today on WP 2.6.5 hosted on my own site and I encountered several problems: 1) option to add CSS clear:both would turn on even if I turned it off in the admin interface, and 2) email would not actually get sent. The former is an annoyance, the latter is kind of a showstopper ๐Ÿ™‚

    I checked the SVN repository and it looks like Mark has been making changes recently; not sure if they address this issue, or if it’s just something stupid I am doing on my WordPress configuration … (although other email functions on the site are working).

Viewing 11 replies - 1 through 11 (of 11 total)