g30rg3x

Well akismet 2.1.8 is now avaliable…
So now the problem is fixed.

Regards

The best-solution is to change the line 727 from:
if ( ! ( isset( $_GET['recheckqueue'] ) || isset( $_REQUEST['action'] ) ) )

To:
if ( ! ( isset( $_GET['recheckqueue'] ) || isset( $_GET['action'] ) ) )

Regards

You can control that behavior within the dashboard panel in the section “Personalization” the setting called “Page Content”.
This setting controls what content should be displayed inside the subpages or “paginated pages”.

In case you are using a personalized template, you should look at Paginated_Comments_content function.

You can read about it in the plugin documentation:
https://www.badspiderbites.com/paginated-comments/

Regards

Hi,

Sorry for being really out for a long time in this discussion.

First pardon me that i haven’t released (yet) version 3.0 of my plugin, this version would be able to address more than 10 bugs in the current “stable” version plus will add new features for normal and advanced users/admins.

Secondly, as i say before most of the bugs and behaviors discussed here has been fixed in the developmental version (currently unavailable for public -yes, its has not been uploaded to the svn-), so again i ask you to wait a little more time, the next version will be released some days after 2.5 is released.

Regards

Hi Alexz,

Unfortunately this is still a server side problem, so m sorry to tell you that there is really nothing i can do (as the plugin main developer).
You should check that you upload all your files correctly and that you have and a supported php and mysql version for WordPress also i totally suggest you to drop version 2.2 and start using 2.3…

Greetings from Mexico

Hi alexz,

I think that problem is directly related to your recently update/fresh WordPress 2.2 and your server.
You should see
https://www.ads-software.com/support/topic/122367
It maybe help you….

Also read this entry…
https://codex.www.ads-software.com/Upgrading_WordPress

Greetings from Mexico

Hi DavidRoberts…

That error means that the SQL Query that should be executed on line 114 is not… for consequence the mysql_fecth_assoc() function cant have a valid mysql resource.

This is related to your mysql user privileges, if your user doesn’t have grant access to Show_view_priv the EXPLAIN SQL Statement will does not work properly.
This is unfortunately a know-bug that is already being work-around in the version 3.0…

If you need further help about contact me over my email, (is in the read btw)

Greetings from Mexico

@sbstextvof:
As stated in the “readme” file and in the warning before the final step, i haven’t fully tested under 2.3.x so i don’t know what behavior to be expected, but my guesses and of course as the main developer of the plu in i have to say: “Why it shouldn’t?”, my guesses is that it will work fine.

But i sure recommend to you (and all) to wait i little time because i started to develop the next version that will have new features, more compatibility across different mysql and php versions and of course a fully support of 2.3.x so i encourage you to wait a little extra time but of course if you need ASAP solution i will suggest to give a try to the current/stable version.

Greetings From Mexico

yes as moshu says,
The “general” (default for utf8) collation should work well for everybody, so i don’t wanna to mess around with this because normally if someone really needs a special collation i think they have the knowledge to do the job himself rather than using automated conversion tools, but in the next version of my plugin i will consider that feature (even i know its really pointless considering that i’m just converting WordPress powered sites, not any type of database)

Hi sfong15,

The codex don’t mention “why you do this or that” because this topic is a little complex and advance so the users that want to do this normally have a partially knowledge about the problem.

The need to convert to the data type BLOB is simply, what the codex is trying to say is that you need to convert the data type (string type) to his binary representations, we need to that in order to avoid problems of characters getting lost or garbage-characters, that it will ruin all our data in a simply. This is a safe-step because normally you wouldnt bother, the only chars affected are foreign chars like the “?” in spanish languages, this char if is not converted before in its binary representation equivalence it will be lost and sometimes screw all your database, so the risk that you have accepted using the script you provide is that, if you have foreign characters they will be converted to trash during the conversion process…

Adding just a little more explanation for why you really need to convert all text(string fields) to blob its because -as i previously says- this is a safe step for converting, because setting to binary it will not be affected the data during conversion and after convertion it will be easy to rollback from binary to string types.
A little list about string-data-type to his binary representations data type is listed next
char -> binary
varchar -> varbinary
tinytext -> tinyblob
text -> blob
mediumtext -> mediumblob
longtext -> longblob
enum -> set charset to binary
set -> set charset to binary

All this fields need to be converted to his correctly representations before convertion, as you can see in the codex thay give the example of converting a text type to blob, but if you need to convert a lets say longtext you will need to change longtext to longblob.

Well 6 days ago i release a plugin called “UTF-8 Database Converter” that easy converts the wordpress database, today i release the second version (2.0) which adds certain new logic an a better solution to the problem.
https://g30rg3x.com/utf8-database-converter/