we-are-ferris

Here we go … While I was away, my customer reset the statistics. I therefore had to wait a few days to get the values back to a workable state.

As already mentioned, the problem occurs with websites that are completely installed in a subdirectory (i.e. also the index.php – and not the installation variant where the index.php remains in the root directory). It makes some difference whether the cookies function is used in Koko Analytics or not (I have both variants for you to look at). The discrepancy is slightly smaller.

It should also be mentioned that there is now a WordPress installation in the root directory. But that makes no difference either. I have had the same problems without, already tested this (more below).

The scenarios in which issues arise are therefore as follows:

Scenario 1:
- empty (root)
+ WordPress 1 (subdir) *
+ WordPress 2 (subdir)

Scenario 2:
- WordPress 3 (root)
+ WordPress 1 (subdir) *
+ WordPress 2 (subdir)

(*) using Koko with cookies (for testing purpose never blocked by our Privacy/Cookie plugin)

Scenario 2 is what is currently used, while scenario 1 was used when I started this thread. For certain reasons, we had to forego the use of a multisite installation. However, we have made some changes in the root’s htaccess, mainly, as additional support for caching and security plugins that we also use (but would also work without) – e.g. use of RewriteCond %{REQUEST_URI} !^/subdir/.*$. Regarding Koko-Analytics it makes no difference at all.

As I have temporarily deactivated the blocking of statistics cookies, I will not publish the links here, but will send them to your email address mentioned above, including screenshots of the current statistics overviews.

Regards

Sorry about that, so let’s continue by email.

To all subsequent readers. Dont’t worry, the plugin works like a charm and also gets its updates as it should ??

Sorry for the late response. I was on vacation. Unfortunately I lost my notebook in the meantime ??
So, I’ll get an overview of the current status and get back to you shortly.

Yes, of course that makes sense. I was thinking something like that too. Actually, my original problem was that favicons (and all those for Android, Apple + MS) are renamed. Of course, it would have been nice if a few exceptions had been made here. Favicon sizes are basically the different thumbnail sizes ?? and if they are named correctly according to the manufacturer, they always have the same name plus the dimension appended. So we have favicon-*, apple-touch-icon-*, android-chrome-* and mstile-*.

However, since this is not a bug or anything, and for certain reasons I need the icon names without this appended “-1”, I have solved it with some rewrite rules in the htaccess.

Many, many thanks for your help and the detailed information on the subject.

• This reply was modified 4 months, 3 weeks ago by we-are-ferris. Reason: Typos and forgot the threat as resolved (sorry guys)

Thanks for your very fast reply ??

Unfortunately, it has nothing to do with the thumbnail versions. To reproduce the described behavior, simply upload an image file with the name test-32×32.png (or any other image type) to your next fresh WordPress installation (no plugins, standard theme – twenty….) and then check the file name in the upload folder. This has been renamed to test-32×32-1.png . When I check the upload folder via FTP, there is now exactly 1 file there, namely test-32×32-1.png and not test-32×32.png as would actually be expected. With a size of 32×32 px, no thumbnail versions are created. And as I already mentioned, this was not the case with earlier WP versions.

Screenshots:
https://ibb.co/RHSNVSj
https://ibb.co/p4WNnrp

Thank you for the info, i solved it via htaccess meanwhile.

Sorry for the inconvenience, but there’s another feature missing – “remove shortlink meta” …
Hide-> General / HTML -> Meta -> Remove Shortlink Meta (Free Version)

… which is even more annoying in a way, because WordPress writes these links in the head for each page
e.g. <link rel="shortlink" > and so on.

You may have a look at this too?

Same here. Can you please explain the following, because i can’t ??
Please keep in mind, i’m always talking about visitors not page views.

Total visitors 543
+ Startpage 918
+ About 652
+ etc

On another website it’s similar….

Total visitors 544
+ Startpage 918
+ About 776
+ etc

Both websites are installed in a subdirectory. The plugin has no problems if WordPress is installed in the root directory. Then all the results make kinda sense ??

Now you’ve beaten me to it. Just wanted to mark it as resolved.
Thanx a lot ??

Ah ok I see, and yes that would be very nice ??

Some people are constantly panicking when they see these weird chars in their emails (but at least a certain sense of security has developed in the meantime, better than nothing).

Regards

Hi @hjogiupdraftplus,

I can confirm that this fix has solved the issue.
Well done. Many thanks for your efforts.

Regards

Thank you for your fast reply. There’s one more thing to mention.

In Avada Forms so-called notifications are used to forward a form to an email address. In the notifications you have the possibility to send all fields or only certain fields. To send all fields you have to enter the following shortcode in the notification: [all_fields]

And I think here is the problem. I don’t know exactly how Avada handles it, but I imagine they grab all the relevant input fields of a form (maybe by type), exclude buttons, their own honeypot fields, etc. and then submit the form.

For smaller forms the Avada/Aios problem can be avoided by not using this shortcode and only using the shortcodes of the fields that should really be sent, e.g. [name] [email] [subject] [message] instead of [all_fields].

I hope I have explained it halfway understandable =)

Here’s the pastebin:
https://pastebin.com/N2u453pJ

What it looks like in the email you get after someone submits the form:
https://imgur.com/a/YzxEN73

Works, thanks for the fix.
Regards.

Thanks for having a look on it.

Thank you for your reply. Fast as always.

When you mentioned the filter, it gave me an idea. Before using your plugin, i disabled automatic updates in the usual approach, by setting a constant in the wp-config and a filter to meet the site health check. Then when I started using this plugin, instead of deleting the constant, I set its value to true. Why? I don’t really know =) So, I think that’s the reason for the error since constants take precedence over filters.

Sorry for my inconvenience.

Thanks for your help. Everything’s fine.