balthazar

I’ve made one possibly interesting discovery about the cookie error while playing with the db tables in my localhost 3.71 installation.

a. Because I’ve had problems with corrupted options tables in the past, I thought to myself “why not use PHPMYADMIN to CHECK my wp_options table.” So I did this, and the table checked-out OK and after, there was, of course, no difference … the beastly little cookie error was still there.

b. But then, just out of curiosity, I used PHPMYADMIN REPAIR on the wp_options table, and mirable dictu, the cookie error disappeared and instead I got an error message about ‘too many headers’. The text of the message pointed directly to line 420 (the cookie test lines) in wp-login.php.

c. Ok, says I, “What if I replace my options table (3 files wp_options.frm, wp_options.MYD, wp_options.MYI) with a set of identically named files from an earlier WP installation”…
Well, I did that, voila, badda bing, the cookie error problem goes away and the login, is completely normal.

So what I think is that there is some connection between people’s options tables and the cookie error… and that there is something in some peoples option tables that is causing the cookie error to manifest itself.

Now it could just be a fluke that I got those results, or it could be meaningful. But I tested the above on three different browsers and two machines (it took most of the day), and I got the same results.

Now, golly gee wiz, I have to go to work this week, so I won’t have time to pursue it… but I’m hoping that someone else will have the time to check it out.

Balthazar

Addendum to addendum to Backups going to wrong folder

Well, I fixed my own problem (Whoopie!)

My first mistake was using if ( !defined('ABSPATH') ) as noted in my most recent post.

My second mistake was in not looking for the plugin’s warning message about file permissions on the backups folder…. but in truth, the warning only appeared once… and only for but a brief moment (you might want to check that out… it looks like a bug)…. and the warning was in a place where it was not very likely to be noticed.

My third mistake, was copying and pasting the example code directly from the backupwordpress plugin FAQ page into my wp-config file.

Here’s what the code on the FAQ page looks like
define (‘HMBKP_PATH’ , ’your directory’);

Here’s what the code on the FAQ page SHOULD look like (sorry for shouting, but it took me four hours to figure this out)
define ('HMBKP_PATH' , 'your directory');

Notice the difference?

The FAQ page uses so-called SMART QUOTES. The correct listing uses normal straight vertical quotes. When I copied and pasted the original code from the FAQ page to my wp-config file, I got the smart quotes … WHICH DON’T WORK (sorry for shouting).

Now that I’ve fixed the quotes, everything is working tip-top, and the backups are going where thery should.

Soooo… in the end, here are several suggestions for your next version of backupwordpress

1. If the plugin sees a problem with backup folder permissions, put the warning and instructions on the MANAGE BACKUPS page (sorry for shouting), where your users are likely to see it right away.

2. On that same MANAGE BACKUPS page (sorry for shouting), include an easy way to set for the location of the backup folder (unless there is a problem with making a change to wp-config.php, in which case provide instructions)

3. On your FAQ page, either make sure that you provide usable code (with regular quotes) or that you warn people about the smart-quotes.

4. Nothing works better than a good example. On your FAQ page,
you’ve only helped users by half measure by TELLING them what they need to do. e.g.. define (‘HMBKP_PATH’ , ’your directory’);

When poorly educated lumox users like me read that, we’re left with all kinds of questions like
a. Duh?? do I need to use a closing slash after my directory?
b. Wha?? do I need to prefix a path from the site root or the WP root to my directory name.

Instead, please please please go the extra distance by helping us with a couple of examples like:

define ('HMBKP_PATH' , ABSPATH .'wp-content/my-backup-folder');

and, please, tell us if we need (or don’t need) that closing slash

If you’ve taken the time to read through this long rant, then THANKS… ( and sorry for shouting),

Balthazar,
Vancouver, British Columbia

[Please stop posting in uppercase & shouting at us. Post de-capped.]

Addendum to backups going to wrong folder

Whoops – its Balthazar again…
In the clear light of morning I noticed one big mistake in my setup snippet above. I was testing for ABSPATH NOT DEFINED, (the opposite of what I needed)… but in fact I didn’t need the test at all because ABSPATH is ALWAYS going to be defined by the time it gets to my little snippet:

So I revised the code… here’s what it now reads:

/** Set up path to the BACKUPWORDPRESS BACKUP directory */
define (‘HMBKP_PATH’ , ABSPATH .’wp-content/backups’);

Unfortunately, this doesn’t fix the problem. Even after deleting and re-installing the backupwordpress plugin, the backups are still going to the wrong place.

Any thoughts?
Balthazar