askapache

Thanks for reporting this in such detail. I will fix this in the next version, among other minor bug fixes. This is my fault.

Stay tuned!

The ultimate goal and ultimate compliment. Thank you!

WARNING: If you lock YOURSELF out of your site: DO NOT JUST DELETE PLUGIN. This plugin ONLY edits 2 files. It does NOT modify other files, it does NOT modify database, it does NOT modify rewrites, just these 2 files:

/home/askapach/sites/askapache.com/htdocs/.htaccess
/home/askapach/sites/askapache.com/htdocs/wp-admin/.htaccess

PLEASE prepare by making sure you know how to access those 2 .htaccess files via FTP/SFTP/SSH/WebDav/WEbFTP/etc… TO FIX:

remove the AskApache Section from those 2 files and CLOSE YOUR BROWSER COMPLETELY AND RESTART IT
If that doesn’t work remove the entire .htaccess files
If that still doesn’t work check your directory permissions (normally 755) of both your / and /wp-admin/ folders.

There is also a SID in the plugin named rewrite loop to prevent redirect loops.

Good description and question, here’s what I’d suggest.

1 Remove all askapache lines and/or .htaccess/.htpasswd files it created. Remove all the askapache plugin dirs and files in wp-content/plugins/

2 Make sure your site has a php error log setup and verify doing an error_log(‘test’); writes to it.

3 Install the newest version but don’t activate.

4 Edit the plugin .php file and set the define for the debug.

5 Clear browser cache. Restart browser.

6 Activate plugin (newest version).

7 Run diagnostics and paste output (obfuscate) or send it to me.. Include the error log lines.

Unfortunately, it’s probably either a writable/ownership issue, or a non-standard server software.

The next version will allow you to just output the htaccess code and let you paste it in manually,a lot of servers can’t use php to read/write those files .

Wow, I am really sorry about this.. fixed in 4.8.3

Fixed in version 4.2.8.5

The problem was #2, bad code on my part that was only unserializing the code for version 4.2.8.3

Here is the fixed code:

function LoadOptions($opts=array('options','plugin'))
{
	foreach ($opts as $pn) $this->{$pn} = get_option("askapache_google_404_{$pn}");
	$this->code=(  (version_compare($this->plugin['version'], '4.8.2.3', 'gte') )
						? unserialize(base64_decode(get_option("askapache_google_404_code")))
						: get_option("askapache_google_404_code")
					);
}

I just noticed this today too… I bet it is being caused by 1 of 2 things.

1. Updates to WP that add filters that corrupt the options
2. An errant key in the last update? Improbable.

It works fine in 3.4-alpha, does not work correctly in 3.3.2 or apparently 3.3.1?

I’ll release a fix this weekend.

There are only 2 files that this plugin modifies. It doesn’t even access your database, or modify anything.

The 2 files are a file named .htaccess in the same directory as your wp-config.php file. The second file is in your /wp-admin/ directory, so: /wp-admin/.htaccess

If you restore from a year ago but do not remove the AskApache code blocks (each file has a block of code in between giant askapache banners. 1 block total for each file.) then you are dangerously unaware of this.

If the giant askapache block is the only text in the whole file, delete the entire file. If it is not the only text in the whole file, just remove the giant askapache block of code. Do that to both of the 2 .htaccess files. Then your blog will be 100.00000% the same as it was.

So, the ONLY issues then (ever reported) can ALL be fixed by doing that. This is true for every version since v1.

The problems are all due to those 2 files, don’t forget that. The common issues people have:

• They aren’t using SSH, and their FTP program or WebFTP program doesn’t display .htaccess files without enabling hidden files first. See your programs docs for viewing hidden files.
• People panic and instead of only removing the giant askapache code blocks, they just delete the entire file even though there was other text in the file ( coincedentally the most crucial code on your blog, the rewrite to index.php that makes WP work ).
• People just delete the plugins folder, and disable the plugin, and don’t realize its only those 2 files that need to be reverted to their previous state.

Very Rarely you might actually have a serious problem that you will need to contact your hosting support to get fixed. This plugin goes a little too far in trying to force solutions to problems writing to the .htaccess files during the install / module activation/deactivation.
In some cases, due to poor or super good security configuration of the web server, or php, the plugin can end up writing these 2 files as a different user then the user you use to ftp. Basically the HTTPD Server is a program that may be started by a special user like ‘nobody’ or ‘apache’ but your website directory is owned by your unique user and group.

If the plugin succeeds in bypassing security to write these files as the user running the HTTP Server, that is basically an exploit, not good. So then maybe mod_suphp or mod_suexec are setup to execute the php binary as a different user, your user, but somehow the plugin bypassed that and wrote the file as the server process owner. What that does is a problem because you don’t know the password of the server user, you can’t login as that user, so that means you cannot delete those .htaccess files.

Cool huh? In that case you must contact someone with the access-level permissions to change the owner and user back to yours so that you can revert the 2 files.

@christinawiler

By adjusting your permalinks wordpress will automatically rewrite the rules to your htaccess file. This will fix the problem that happens when the wordpress code block is deleted from the .htaccess file.

It is entirely my fault for these problems, but I hope you will learn things about your site and servers security you didnt before. And having to contact your webhost is always good as it keeps them on their toes. The next version fixes these issues.

Does your AuthDigestDomain include / or wp-login.php? I changed the current version to not be as clear on that. Check httpd.apache.org

Your blogroot .htaccess file should have something similar to:

<Files wp-login.php>
Satisfy Any
AuthType Digest
AuthName "Protected by AskApache"
AuthDigestDomain /wp-admin/ https://www.askapache.com/wp-admin/ https://www.askapache.com/wp-login.php
AuthUserFile /home/askapache-mirror4/.htpasswd
Require user gravedigger
</Files>

There is no way to view wp-login.php over remote http(s) unless you login… so there is no way the prompt wouldnt appear (unless you already logged in, logins are cached by all browsers until the browser is closed).

I think the sneakiest problem is all these webhosts don’t have errordocuments setup by default… which is truly amazingly bad. Another amazing problem I hear sometimes is that some hosts using various servers that are not always apache are saving money by only updating the server config from a directory-context .htaccess file once an hour, or longer!

Make sure you have setup LOCAL errordocuments (in your blogroot .htaccess)..

ErrorDocument 401 /errordocs/401.html
ErrorDocument 403 /wp-content/403.html

# this just guarantees they will use the right status code,  may need.
#Redirect 401 /errordocs/401.html
#Redirect 403 /wp-content/403.html

An example 401 is @askapache.com/show-error-401/, an example 403 is @askapache.com/show-error-403/, actually all 53 errordocuments.

I have no idea what is wrong tervan.. I am debugging it as much as I know how and it’s clean.

Please give me any errors, a screenshot, as much as you can..

Wow big mistake on my part, sorry about that! Got a little anxious to get the update out there..

I just released a fix 4.8.2.1 that fixes that and a jquery.cookies issue.

BTW, please keep sending me any ideas for improvements, I implemented a ton of suggestions with this release and want any ideas for improvement you can think of. This plugin is a set-it and forget it deal because it’s used on so many sites, so it has to be 1-click and it works. The 404 Google Tracking Code with asynchronous javascript? My favorite.

Again, sorry for that coding error.. it’s really not cool that it caused php errors to show up, a potential security problem for sure..

Ok I just uploaded a new version, pretty drastic code differences (for the admin side of the plugin) but I wasn’t able to fix the main postbox issue, just haven’t had time and it is confusing.

Instead I made all the boxes visible by force of css. If you can figure how to fix this new version 4.8.0, please let me know!

or it could just be that you haven’t read the docs which explain how the login is saved until the browser is closed.. you can’t log out of the htaccess sigh, its totally different than WordPress login, or any other authentication plugin.