robf

Just tested my site (same as Slimstat support were testing) with php version switched from 5.6 to 7 and as you indicated, silenx, it then works fine (no increase in memory/file size etc over config for 5.6, just version change)

Perhaps SlimStat support can now test and investigate further under php5.6 to eliminate what seems to be a bug in Slimstat when running using browscap db on that version.

I’ve copied php error log from my site when running browscap under php5.6 into my ticket with support.

• This reply was modified 9 years, 8 months ago by robf.

I’ve been having this problem too, and SlimStat support have been testing direct on one of my sites. As it may help others, I have copied here their explanation for this particular instance, and my response below:

Explanation from Slimstat:

Hi Rob

thank you for all the info. I was able to spend some time testing a few things, and it turns out your server is not loading the entire data file for some reason. This breaks the code because some strings are not defined (while they should be) and that’s why you get the empty strings in the Activity Log (question mark icons). You may want to look at the error log or other php configuration files to see why this is happening. It is definitely not happening on our live server ( wp-slimstat.com ) so it must be something in your server configuration.

Once that problem is solved, then everything should be back to normal. In the meanwhile the heuristic function (uninstall Browscap) is a valid alternative, given your server constraints.

Best Regards,
Your Slimstat Support Team.

My response:

Thanks for the explanation, and for diagnosing.

It is probably a constraint on use of resources on most shared server hosting, and given that, I think you’ll find that it will affect a lot of websites running your software.

If you can tell me the max size this file is I’ll see if I can change the setting – I think it is currently 8Mb.

Regardless of that, loading and checking an 8Mb file is pretty heavy on resources (and will affect speed too) so I for one will be avoiding use of browscap unless you can find a way of reducing its impact on site performance (main reason I started using slimstat instead of jetpack’s stats).

Best,

Rob

Just for info, if anyone else is getting issue with data not being displayed properly using browscap db I can confirm that setting back to heuristic solves the problem, so definitely looks like a bug.

Look forward to response via my support ticket tomorrow as time zones got in the way (uk here)!

Whilst the update hasn’t broken any of my sites (I updated about an hour ago, and all running PHP Version 5.6.25), I have found that after switching from heuristic to new browscap option, the icons don’t display properly for browser or operating system (and operating system doesn’t display at all).

Any idea why?

I thought the new option was meant to be more accurate. At present it is failing to register information

In another thread posted 18hrs ago, you said that a fixed version would be available today or tomorrow.

According to github link above, looks like the patch for this particular issue was completed 18hrs ago but in the meantime new issues continue to be added to version 4.3.1

Given the widespread chaos this issue is (still) causing, how about either patching 4.3 so its usable or getting 4.3.1 out ASAP and adding new issues to 4.3.2 so that we have usable sites without having to faff about with previous versions to get Jetpack working.

• This reply was modified 9 years, 9 months ago by robf.

Getting “Error fetching static.html” on settings and dashboard pages after upgrade to 4.3 – consistent across several sites (normal behaviour on others I haven’t up(?)graded yet)

I’d also like to know what will happen should I manually remove plugin folder as described? Will settings still be held in MySQL db?

notifications from All-in-One Event Calendar by Time.ly working for me via this plugin