ice00

hi,

resolution of this in next version (being testing)

thanks

hi,

thanks for the report.

Tomorrow will be released the 1.2.7 version, I will see if I’m able to integrate already this stylesheet fix

hi,

almost 99% of service provider limit the time a script can be executed into the server side before killing it for using too much cpu usage on the server (this time is about 15 seconds in average).

This has limited any kind of approach to reduce the DB usage by storing the data in some manner in other tables.

I made many experiment into the past using my DB (over 1,5GB of data) but due to the kill of PHP process by the server that interrupt the table migration, the procedure fails in a non consistent state (e.g. missing data or duplicate data from one table to an aggregate one). Such scripts instead needs even minutes of running time to convert such big database ??

The unique remainin approach to a solution could be to have some cron jobs that run for some seconds every minutes onto the server and convert a piece of DB at time. It will tooks maybe weeks to convert the DB, but the problem is that not all the service provider gives free access to crons jobs and some providers only sell that usage!!

A similar approach is that at every page visits, a peace of DB will be converted, but first, the page generation will be delayed and second it tooks months to convert all the DB ??

So at the actual time you have two partial solutions. First is to allow the automatic purge of the spiders visits. Maybe spider visits is a not vital data to see, so deleting spider visits older that one month is a good solution to half the DB usage.

Second you have to purge the old data and use the offset value setting for showing the sum of deleted data (please note that in this version offset are not working as sanization required by WordPress has break that features, but we are working to fix it in next version).

So, if you had a total visits of lets say 2.500.000, and after you prune a year you get a 1.000.000 visits, then you had to put 1.500.000 as visits offset in NewStatPress option.

Please note that big database and/or lighter database after prune will have a big hidden problem that could pop up.

At DB level, the ID is defined as:

id mediumint(9) NOT NULL AUTO_INCREMENT,

that means it can store up to 8388607 records then every storing will give a hidden error and no data will be added to DB.
Maybe when StatPress were created that seems a big values, but I have already surpassed it in one of my site!

A solution of this seems easy:

id unsigned mediumint(9) NOT NULL AUTO_INCREMENT,

this double the capacity (16777215) with the same DB usage by using unsigned number over signed one.

The problem is still the service provider limits: such instruction, at DB level, need minutes to run with big database so the provider blocks it and the result is that you will not be able to see your page (as DB table variation update is running at every page visits!).

To end this, the unique pratical solution should be the cron jobs that will take the DB table with 3 months of data and aggregate it in other tables, but this is not yet coded.

hi,

sorry, it is not jet ready. It is more difficult to achieve that I was thinking.

you can temporally modify the PHP (look at file variable.php inside include/api/). For example, if you want to modify the %alltotalvisits%

  if ($var=='alltotalvisits') {
    $qry = $wpdb->get_results(
    "SELECT count(distinct urlrequested, ip) AS pageview
     FROM $table_name AS t1
     WHERE
      spider='' AND
      feed='' AND
      urlrequested!='';
     ");
     if ($qry != null) {
       echo json_encode($qry[0]->pageview+$offsets['alltotalvisits']);
     }

then you have to add your fixed amount before $offsets (eg, suppose it is 1234):

     if ($qry != null) {
       echo json_encode($qry[0]->pageview+1234+$offsets['alltotalvisits']);
     }

you can email at newstatpress [at] altervista.org your fixed values and I can send the modified file to you if you are not able to modify the source.

thanks

hi,

unfortunately it needs to rewrite part of the code that affect counter option saving for being able to fix it and this is not simple as planned ??

So I have to test the fix a lot before releasing it.

I hope to have it ready in a couples of days.

Thanks

hi,

It is probably broken due to the new sanization applyed.

It will be fixed in the version of tomorrow.

thanks

If you only need to have the starting date October, 17 2005 (leaving all the collected data as is) and you had activated NewStatPress after that date, then you need to modify one record and put that date in it.

You need PhpMyAdmin for enter the table wp_statpress and then modify the record by hand (in DATA field).

Else you could use an SQL instruction like this:

UPDATE WP_STATPRESS SET DATE=’2005/10/17′ WHERE ID=1;

Thanks

Hi,

“Statpress “Visitors” and NewStatpress uses the same table (wp_statpress) so they should not be used together (otherwise you record twice data).

Please try to use the repair table function onto NewStatPress utility as I suspect you had a damaged table.

Else try the new version as it has a new API implementation.

thanks

hi,

actually the plugin start to show data from the first record stored (unless you use the prune option, so it start from the last XX days/month you choose) and it is not possible to put a starting data.

thanks

Hi,

NewStatPress uses the wp_statpress table created into the DB, so unless you did not use the option we add of Erase table, the data will stay in that table even if you reinstall the plugin.

thanks

hi,

I send an email with “[NEWSTATPRESS] P1” object.

thanks

hi,

I think that you only need to include the wordpress core from php (use ../ as needed for the right position relative to your script):

require( '../../../wp-load.php' );

if this not works, then you need to include even newstatpress.php and add a call to
nsp_StatAppend()

thanks

hi,

I was attending your replay to the email I sent for being able to test the API in your site.

I will resent it tonight if it goes lost.

Thanks

hi,

I need some information about your multi-site to test the stuff but it is better if you drop an email at newstatpress @ altervista.org so I can ask for some technical details and screenshot directly there.

Thanks

hi,

your DB is probably big and as usual server provider blocks PHP script that run for many seconds, so you get 404 errors.

You can see the dimension into the Information panel of Tools in NewStatPress.

We are implementing the External API to mitigate this problems: instead of a big call to the server, there are many asynchronous call to the server and the page is showed immediately, then it will populate as data arrived.

Unfortunately now it only coded the Dashboard and Overview graph, all the others are being implemented.

You can reduce the DB activating the prune of spider, or in the worst case by pruning even of user visits. Those however delete the collected data.

Thanks