Sidebar Caching Issue

[sadams101]

After upgrading from 4.6.7 to 4.6.9 I am noticing that my sidebar caching, at least 50% of the time, is not showing my ads. Once I clear the cache the ads show up again, but this never used to happen. Is there a sidebar caching issue with 4.6.9?

[Ehren]

Hello,

When the ad fails to load, can you check the browser console or use the web inspector to see if the ad content is actually loading? It could potentially be caused by a problem with your ad network rather than the Invision software.

With that said, it appears as though you've implemented your ad by modifying the HTML code of the Member Statistics block. If you have the Pages application, a more flexible method would be to use the built in "Blocks" feature and the "Advertisements" feature. This will allow you easily to drag/drop/reorder your advertisement into any widget location in your sidebar. You can learn more about that here.

[sadams101]

The issue with loading ads using the method you mentioned is that all ads for all devices are still loaded, even though the only visible ones are those with the CSS settings done per device. The only way I could stop ads from loading for other devices which were hidden by CSS was to use my method, plus using a 3rd party plugin that was working to stop this behavior. 

My ad network is on my server (Revive Adserver), and hasn't changed since this upgrade. The only change was updating IPB, and now, if I go to the different areas that they should show up they do not about 50% of the time. When this happens, if I clear the cache in the support area, it fixes the issue...for a few minutes anyway. The issue is definitely related to the upgrade.

[Marc]

Unfortunately as this is something you have modified, we are unable to assist with this, as this is custom code and the block you are using and amending isnt really built to be used in the manner you are using this.

[sadams101]

Actually I am using your feature called "Define your own location":

Did you not intend for anyone to actually do this? 😄

But the bigger issue that I think you might want to think about, especially for site speed and those who use google ads, is that why, if I use my own CSS tags like this:

<div class='ipsResponsive_block ipsResponsive_hidePhone'>
My Ad Code here
</div>

OR if I use the check boxes you provide in the Blocks method, which allows you to check the same boxes to only show the ad on Desktop and Tablet, why do the ads still load on Mobile (they do, I've verified this using Google speed tests...you just can't see them on Mobile, but they do load)?

This is a big issue, as it causes google ads, for example, to load ads that will never been seen or clicked on, thus, dramatically driving down your CTR, and causing advertisers to drop you as a place to show ads.

PS - I also tested my Blocks versions which no longer work after the upgrade. To get them to work I had to re-create them. I suspect that if I re-create the ones I'm using now it may fix my issue as well, and will let you know. Does this provide any clues here? Why would the database references be gone or corrupted after the upgrade?

Edited December 22, 2021 by sadams101

[sadams101]

Update: Recreating the ads in the database did not fix this issue.

I ran an experiment where I put in the word "Mobile" in place of the mobile ad code, and "Tablet" in place of the tablet ad code, and the correct ad code for Desktop ads, and to me it seems that the cause of this issue is the right column is getting cached by a Mobile or Tablet user, because when the ads don't show I could see either "Tablet" or "Mobile" instead of the ad. 

I also saw no way to turn off the sidebar, header and footer caching, and could only set this to 1 minute, but not to OFF.

[sadams101]

I also have the issue where the setting for "Cache sidebar, header and footer blocks" will not stay to where it is set. It was set at 16 minutes, but if I change it to 1 minute then log out and log back in, then check that setting it goes back to 16 minutes! I've reproduced this 10 times, and it does this every time. Why?

[sadams101]

I think I solved the issue of not being able to save admin settings. I saw this error on the Data Storage page when trying to save anything:

• In order to enable this setting you must make the /path/to/task/task.php file executable (i.e. chmod 0777).

I have always had this chmod 0644 without issues, but after the upgrade something changed. Is 777 even secure?

Now I am able to save admin settings.

Unfortunately this did not fix the caching issues I am having with my ads. Mobile or Tablet versions of certain areas are still being cached and served to desktop, which seems to be the cause of my issue.
 

Edited December 22, 2021 by sadams101

[Marc]

I feel you are misunderstanding my original statement there. Using that custom code within a cached and prewritten block like that is not what that block was designed for.

Please note, while we provide the ability to use  custom location also, we do not provide assistance with your own custom code. I understand what you are saying by we are providing that possibility, however we also provide the ability to add plugins and applications, the ability to update themes, and the ability to translate. All of which we would not provide support with if those customisations break the site

[sadams101]

I realize IPB's ability to provide support now seems to have become severely limited (at least in comparison to my experiences prior to 5 years ago), which is why I've posted this in your forum. 

Perhaps you already know what programming changes were made that would cause this big change in how those blocks are cached, but if not I think it could be important for you to figure this out, as I've displayed my ads for years this way without issues. Perhaps there is a coding issue? It would certainly not be the first time.

Also, in this thread I've pointed out another (what I believe to be a serious) issue with how ads are delivered--the fact that even though desktop or tablet ads might be hidden to the viewer using the desktop, tablet, mobile check boxes you provide in Blocks, or by wrapping the ad code in the CSS tags that hide them from various devices, the ads hidden from mobile are unfortunately still loading in mobile (in the background), which makes it nearly impossible to make money with Google or other network ads for obvious reasons (and this also greatly slows down the mobile version for those who run ads). If what I've described is actually happening, wouldn't you agree that this is an issue with the software that should be addressed?

Edited December 23, 2021 by sadams101

[Jim M]

16 minutes ago, sadams101 said:

I realize IPB's ability to provide support now seems to have become severely limited (at least in comparison to my experiences prior to 5 years ago), which is why I've posted this in your forum. 

This has been our policy for quite some time, very long before the recent change to support forums (it has been our policy since I have been a part of support 6+ years). While I certainly understand that you believe there is an issue here and that it should be assisted with, you have to realize we do not support customizations. 

Caching is meant to cache what is present and display that on devices available. If this happening only with your advertising code and in a custom location, I would advise investigating this further with other variations and troubleshooting this with your advertisement provider. I do know that Google AdSense will not serve advertisements on every page load for every URL. It analyzes the client, URL, and more (much beyond what is published) to determine if it is worth it and the bid in place.

 

24 minutes ago, sadams101 said:

Also, in this thread I've pointed out another (what I believe to be a serious) issue with how ads are delivered--the fact that even though desktop or tablet ads might be hidden to the viewer using the desktop, tablet, mobile check boxes you provide in Blocks, or by wrapping the ad code in the CSS tags that hide them from various devices, the ads hidden from mobile are unfortunately still loading in mobile (in the background), which makes it nearly impossible to make money with Google or other network ads for obvious reasons (and this also greatly slows down the mobile version for those who run ads). If what I've described is actually happening, wouldn't you agree that this is an issue with the software that should be addressed?

The only means currently which we have to detect and show elements on page to desktop/table/mobile devices is through CSS. This would still render the elements on page but would simply hide them. You are more than welcome to post a suggestion in the Feature Suggestion forum but currently, this is how it is designed.

[sadams101]

I made the feature suggestion. 

I also disagree that I'm using the IPB "Define your own location" for ads in a way that was not intended. What did you mean by "Define your own location"? I did do this, but now you're essentially telling me that because I did this you can't help me? Strange response indeed.

[Marc]

On 12/23/2021 at 7:54 PM, sadams101 said:

I made the feature suggestion. 

I also disagree that I'm using the IPB "Define your own location" for ads in a way that was not intended. What did you mean by "Define your own location"? I did do this, but now you're essentially telling me that because I did this you can't help me? Strange response indeed.

To explain further here. The feature itself you have used is indeed working. However you have placed it in a location in templates that isnt havent the effect you intended it to. In this case it's a location that is caching. 

[sadams101]

Understood, and as mentioned, the way I've displayed these ads worked just fine in that location for at least 2 years, until this upgrade, which is why I brought this up in your forum.

Whatever cashing changes you made to those blocks in the last two updates seems to no longer account for the viewing device, which can lead to other issues, not just this issue. 

I actually have had to turn off all of your cashing features, as I've discovered (and reported in older threads here) issues with cached pages that are related to incorrectly cached pages per device. Unfortunately I am unable to turn off this cashing feature, which now seems to also have the same issues.

[Marc]

Our block is intended to work in this manner. If you dont wish for it to be cached in this manner then you would need to add your code somewhere outside of the item that is being cached. 

[sadams101]

Ideally I would be able to turn off any and all caching. I will try to recommend this as a feature.