Forum Replies Created

Viewing 15 replies - 1 through 15 (of 19 total)
  • Thread Starter Statistiker

    (@statistiker)

    Dear Jason,

    I appreciate very much, that you take this issue so serious! Unfortunately, I am not available for the next week but I will come back to you as soon as possible. In the meantime, I will try to isolate the problem, at least to the server configuration / slimstat / email reports by switching of again any plugin and by changing the theme.

    So again thank you very much for your support!

    Martin

    Thread Starter Statistiker

    (@statistiker)

    Hi Jason,

    in SlimStat (current version) section overview the following fields are working:

    -visiter yesterday
    -visiter today

    what is not working:
    – pageview graph: only the gray curves are displayed not the green and yellow one for the actual month
    – in days in range it is always assumed to have 31 days regardless of the filter

    So as stated in my posts above, Slimstat is not using the date range, which you can select in the top right corner, which should at the moment go from the 1st of April to the 7th of April but instead it displays the data of the last month I guess.

    Switching EMail Reports of solved the problem, however by switching it on again the problem is back there. Thus, it is not a one time problem.

    In case you need further information, I could also send you a screenshot of the report.

    Thanks for your support!

    Best regards,

    Martin

    Thread Starter Statistiker

    (@statistiker)

    Dear Jason,

    thank you very much for your answer! Indeed deactivating other plugins helped, however I guess you dislike my answer: The Slimstat Email Report plugin is crashing the normal slimstat report, as it is not showing the correct date range.

    Hopefully you find a solution for this problem. I am using EMail Reports version 3.2.1.

    Best regards,

    Martin

    Sorry, I just realized, that you didn’t advice me, to disable the dashboard widgets, in the dashboard settings, but instead go to slimstat->settings and disable there the dashboard widgets. This also works fine.

    Thanks,

    Statistiker

    Dear Camu,

    thank you for your quick answer. Unfortunately, I already tried all of your advices like disabling UAN, disabling dashboard widgest, setting tracking mode to client, etc. Nothing helped. So I did the following:

    I opened file wp-slimstat-admin.php in folder admin located the section Dashboard widgtes and commented out the following lines until the wordpress widget section. In this way, the dashboard now loads fast again. So I guess the problem is, that all the data is loading while calling the dashboard, even if the corresponding dashboard widgets are disabled. In this sense, it seems to be quite ineffective. What do you think?

    Hi Camu,

    sorry for reopening this thread, maybe I should create a new one.

    Actually I have the same problem as icolove: Slimstat totally slows down the dashboard. Other admin pages are hardly affected, mainly dashboard and slimstat pages. Turning off slimstat is eliminating these issues. Since I had no problems before, I think it started with one of the last updates.

    Maybe you can still find a solution to this problem, as this is a severe drawback at the moment.

    Best regards,

    Statistiker

    By the way, your problem was already reportet 1 year ago:

    https://wordpress.org/support/topic/false-positive-on-jpgs-in-gallery

    Finally, I can tell you what is wrong with your plugin:

    In my case, I have a rather large blog, with different authors. On the one hand, they can all upload files and on the other hand, I have no time to check every mime type. Actually, some people managed to create a jpg-file with a pdf mime type which is not filtered out by

    if ( $wp_post->post_type != ‘attachment’ || $wp_post->post_mime_type != ‘application/pdf’) {

    Therefore, I had to insert an additional condition

    $pos = strpos($src, ‘.pdf’);
    if ($pos === false)
    return;

    In order to check, whether .pdf is part of the filename. Otherwise I will exit the function without adding the <object> tags, which crashed the WP galleries.

    Now I think my problem (and that of pinkylips) is solved, but from a good plugin I would have expected a better support instead of not responding.

    Thread Starter Statistiker

    (@statistiker)

    Great it works again after changing t1.resource to resource. Thanks!

    Thread Starter Statistiker

    (@statistiker)

    Sorry for bothering you again, but since version 4.x it is not possible any more, to get the top pages by filtering via

    wp_slimstat_db::init(‘day equals ‘.date(‘d’).’&&& interval equals -7 &&& content_type equals post &&& limit_results equals 50′);

    $results = wp_slimstat_db::get_popular(‘t1.resource’);

    I guess that the column identifier t1.resource has changed. However, I don’t know how to fix it. If I just call

    $results = wp_slimstat_db::get_popular();

    $results is a non-empty array with data related to post, however if I call

    $results = wp_slimstat_db::get_popular(‘t1.resource’);

    $tesults is just an empty array.

    Hi Mike,

    unfortunately, I have the same problem with standard wordpress galleries. Can you already provide a fix for this bug? Gallery images are either not visible or the stylesheet is changed.

    Thanks for your efforts!

    Thread Starter Statistiker

    (@statistiker)

    Hello Camu,

    sorry for bothering you. My problem was that instead of

    ‘day equals 1, interval equals’

    I needed

    ‘day equals ‘.date(‘d’).’, interval equals -6′

    Actually my mistake was to copy it from the shortcode faq page, where day equals 1, interval equals is listed for shortcodes.

    At the end of the day it works and I am happy for that great plugin!

    Thread Starter Statistiker

    (@statistiker)

    Thank you!

    Since yesterday the bug removed. But I think it’s most likely correlated to the change in month. That’s also the reason why I asked, whether I have to specify the date range since the last versions. Maybe I should wait till end of April, whether it appears again or not.

    I also don’t want to exclude a bug on my side.

    Best regards.

    EDIT: Oh I have something to add. Somehow the

    wp_slimstat_db::init(‘content_type equals post’);

    line is ignoring ‘content_type equals post’. It also returns custom post types and pages instead of posts. Maybe there’s the bug?

    Thread Starter Statistiker

    (@statistiker)

    Sorry to bother you with an old problem.

    In the last view month I was able to get the most popular post by

    wp_slimstat_db::init('content_type equals post');
    $results = wp_slimstat_db::get_popular('t1.resource');
    foreach ($results as $result)
    {
       ...
    }

    But since a view days ago there is a great discrepancy between the output of the lines above and the top pages part in the report in the dashboard. I guess that some of the last updates might have caused this issue? Currently I am using the version 3.5.7. With 3.5.1 it definitly worked.

    Do I have to specify the date range now when calling init(‘content_type equals post’)? Or has anything else changed? I checked the changelog but found nothing.

    Can I provide you any helpful informations?

    Thanks for your support. It’s always great!

    Thread Starter Statistiker

    (@statistiker)

    Dear Camu,

    thank you for your answer. Just pressing the increase performance button helped not much, actually I noticed no difference.
    My problem is not concerning the load time of reports, because I can wait, but the normal homepage is loading slow.

    I guess version 3.5.6 will come out anyway so let’s give it a try. By the way Slimstat is reporting MyISAM as a db engine.

Viewing 15 replies - 1 through 15 (of 19 total)