SteveW928

Joost,
Might I (we) inquire as to why? While I’m quite a noob at both SEO and translations, qTranslate seems to be the best solution short of doing a blog for each language (which is a TON of work, especially for non-profits and such that don’t have a lot of resources).

From my research, qTranslate seems to be the best (only?) solution for people in my situation. I can’t imagine there are not 1000s of us. I’ve read a lot of threads and looked a bit at the ‘hacks’ and while I’m no php developer, I’m not completely ignorant either; it doesn’t seem incredibly far-fetched that such interoperability could happen.

It’s your plugin of course, but with the international nature of the Net, it seems like making it a bit easier to do this kind of basic multiple-language support would attract a lot of folks to your plugin. It seems you’d only have to make a more stable path to allow qTranslate META to take over those couple fields (as people seemed happy with that in previous versions), or support the generation of those extra fields within the plugin.

A bit more explanation would help many of us who are struggling. Thanks!

I haven’t set up my Google and Bing yet, but when I setup (claimed) my site in Alexa, it gave me a code to insert into my site. That is what goes in that box. I’m assuming it will be the same for Google and Bing, once I get to that. (Note: I’m a noob too, but I’m pretty sure I got this one right, so can start helping… ?? )

I think it is just those two fields on the ‘home’ tab, but I agree that it isn’t exactly clear to a noob like me. (Just wanted to add a me-too in case the authors might want to add a bit more on that to then tour or instructions). I haven’t gotten the results yet either.

Also, I was a bit confused on the instructions to search, as there seems to be no way to search the support forums concerning one (this) plugin…. you can only search the whole thing as far as I can see.

I’ve been researching the same thing. It would be REALLY nice if these two plugins could play nice together, or if Yoast would add the ability to create multiple language fields for the META description and title (while I’m a noob at this, those seem to be the two most relevant things to show up in search results in a meaningful way).

While I’m sure this would require some effort, I can’t imagine that 1000s of people aren’t in this same exact position.

Just a follow up… the author of Bad Behavior looked into the issue and found a way to fix it. He indicated that it should be in the next release of Bad Behavior (ie: after v2.1.15).

I’m having this same problem (hovercards show in admin panels, but not in site comments with viewing the site as a normal user would). It isn’t that line in footer.php indicated above, as I do have that in my footer.php file.

However, out of 3 sites I manage, 2 are working fine… which leads me to believe it does have something to do with the theme. I just don’t know where to start looking.

Thanks Mike. I did figure out how to get back in, but good to put it here for others.

I’m aware I can pick other combinations of plugins, and might consider that. I was mainly wanting to make you (and the author of Bad Behavior… as well as others who might try this combination) aware of the problem so you might be able to make them compatible (and add another to your list). ?? It was definitely some change made in Bad Behavior that introduced the conflict, but I don’t know what it is.

I’ll third it!
If they get the captcha wrong, they should be told they got it wrong and asked to reenter it (it would only be ignored if they keep getting it wrong and give up… otherwise, they are probably a legitimate user who just got the captcha wrong). If they get it correct, then Askimet or whatever can decide to put it in the spam or pending… or publish it, etc. Captcha should be a first line of defense against automated entries.

Also…. Please add the login page. I know there is another plugin for this, but I’m not sure why it wouldn’t be included. Wouldn’t that be a good page to protect with a captcha? I’ve got a strong password, but still, it seems better to just reject attempts.

Yes, I think so… and the problem (for me anyway) is telling the difference. So, I think that neither strategy: a) changing only the table names, or b) doing a search and replace on everything ‘wp_’, are going to actually work. ??

The good news is that as far as I can tell, my blog is working fine. Hopefully I’ve picked enough of the right ones that what is left is obscure references I maybe don’t use anyway, and hopefully I didn’t change any of the functions I wasn’t supposed to.

So, in my experience now, DB renaming isn’t nearly as straight forward as some of the articles make it out to be. Proceed with caution folks. I think my other blogs are going to remain wp_ for now. I’ll just hope the WP devs have some really good ‘cleaning’ code on inputs to the DB.

Good to know, I’ll send them an e-mail. I think it read the wp-config when it (the plugin) initially created tables, but then after I changed table names, it created a new set of tables, still named wp_ and started over recording data. Fixing the name it had in one of the wp_options table pointed it at the original tables (now renamed).

As for the remaining wp_ instances, I’m down to just a few. A few of them are maybe variables, and not meant to be changed (ex: there is a ‘wp_me’ under table: wp_options, col: option_name data: stats_options). The other few might need to be changed, but I guess I’ll wait till I run into some kind of issue or run across more info.

For example:
table: wp_options col: option_name data: wp_db_backup_excs

table: wp_options col: option_name=cron option_value: several wp_ variables in here

table: wp_postmeta col: meta_key data: _wp_page_template (a few of them)

table: wp_options col: option_name=sidebar_widgets option_value: wp_inactive_widgets in it)

There are a bunch of entries in table wp_options where option_name is:
_transient_xxxxxxxxxxxxxx (xxxx is some name). Many of these have wp_ things in the value, but I’ve not changed them, as I’m guessing they aren’t that important, and maybe are just non-related variables anyway.

Just for the sake of other readers… a few of the places you need to change:
(I’ll call them ‘wp_’ but you will have renamed to ‘yourname_’ already, so take that into account). BTW, this isn’t an exhaustive list…

table: wp_options col: option_name data: wp_user_roles (change to yourname_user_roles)

table: wp_usermeta col: meta_key data: wp_capabilities (several of them), wp_user_level (several of them), wp_autosave_draft_ids, wp_usersettings, wp_usersettingstime, wp_dashboard_quick_press_last_post_id (again, put yourname_ in place of wp_)

My initial 70-some included a bunch of records the stat plugin had been recording, so they are rather irrelevant for me to change or worry about.

@ Rich ‘elfin’ Pedley –

In my experience (limited so far), that isn’t true. You also have to change internal references within the table data. There are several sites which outline instructions, and list several modifications you have to make, otherwise you’ll get page telling you you can’t even log into your site.

However, I’ve found that these instructions don’t seem to catch all the occurrences anymore in WP 3.0.1. Some plugins also seem to store references to wp_ names (WassUp for example).

I’ve read on some sites to export the DBs, search and replace all ‘wp_’ with ‘yournewprefix_’, and then, drop the tables (not the db), then re-import the data. I have not tried this, but in doing a search, I come up with like 70+ instances of wp_, and some don’t look like they might be references, so I’m not sure about that bit of advice either (and this is after I hand fixed everything I could see, and have my site, apparently, running OK again).

So, I’m a bit confused at the moment, and hoping I can find some more answers, but I know it isn’t as simple as just changing the table names.

BTW, I used the WP Security Scan plugin to do the initial change, which did some of this for me, but didn’t completely work.

Note… not just table names, but also references to the wp_ names in the data in the tables (though I’m still unclear if it is all, or some, etc. I have a lot more wp_ occurrences in my DB than most of the web instructions for changing the prefix indicate).

But, esmi is correct that this a very different thing than the filenames and folder names of the wordpress files. Those, you don’t want to change. I’d recommend doing a google search on something like ‘changing wp_ prefix for wordpress’, and read some of the articles. One good page I ran across is:
https://guvnr.com/web/blogging/10-tips-to-make-wordpress-hack-proof/

However, I ran into issues after changing the prefix… so you should be cautious on that step… have backups, etc.