scott001

I am not using GeoIP for my ads, and do not have an account or license for the GeoIP plugin, but I am receiving the following warning from Maxmind. Is there anything I need to do, or that Revive needs to do, regarding this warning? Hi, We’re still seeing outdated API requests from your account (ID 23XXXX) that are using an incorrect endpoint. Going forward, we will only accept: API requests sent with the more secure HTTPS protocol. API requests sent to the appropriate hostname. Click the links below to view a list of valid API hostnames for each service.

I have a very simple delivery rule set on a few banners, which is a Time - Date rule "is later than or equal to" and I've selected 15 November 2023 as the date. Unfortunately the banners with this rule are showing now, long before that date. Do these rules work?

It looks like you can change strict mode according to this site: https://www.phoca.cz/documents/50-phoca/625-strict-standards-non-static-method Are you running the IPB update via your Admin ACP? If so, there should be error messages if there is an issue.

I am running Revive 5.2.1 with v5.5.5-10.3.30-MariaDB and don't see any issues. What issues are you having? You didn't really describe your issue. Also, I have strict mode off.

No solution yet, I still have to create the links manually for them to work.

I did find a way to make this work. When adding a banner if you select the External Link option, then just link to the banner on your server, it will properly serve a webp banner and it does display correctly.

Hard to believe this hasn't been answered, but it doesn't seem to support it. I just tried replacing a banner with a webp version, and got an error.

Thank you for sharing!! Just to clarify, on line 3436 I added this: $imageTag = "$clickTag<img src='".htmlspecialchars($imageUrl, ENT_QUOTES)."' width='$width' height='$height' alt='$alt' title='$alt' loading='lazy' border='0'$imgStatus />$clickTagEnd"; Revive coders...are you listening? This is an extremely simple solution to speeding up serving banners with your software, can you please add this to the source code?

I've noticed two things when I use the asyncjs.php script to load multiple banners per page on my site that make me question whether or not the async code is doing what it should be doing: 1) If I remove "async" from the script tag, so this: <script src="/adserv/www/delivery/asyncjs.php"></script> instead of this: <script async src="/adserv/www/delivery/asyncjs.php"></script> I get faster page speed scores from Google. There is no comparison, at least 10% faster. Why? 2) Google penalizes me for not lazy loading my banner ads with async loading. I thought that if you load something async, everything else on the page will load without delay, and the async loaded content will load simultaneously and not slow anything down. The fact that I'm getting a 1.5 second penalty from Google about not lazy loading my ad banners tells me that perhaps the async script is not functioning as designed. Any help would be appreciated!

Or you can just ignore this and nearly every other post in your forum...it seems like nothing ever gets a reply here. I'm not sure who's running the show, but it seems like most issues posted here go unanswered. Why bother having a forum at all? Just ignore it, and it will go away, right?

I'm looking for the same information, but since you've gotten no reply to this in 8 months, it doesn't look like they want to help those affected by their security issue.

Any word from Revive on this??? Just ignore it and it the issue will go away, right? Thank you for sharing this. I was just reading about a widespread exploit against Revive, but can't find anything here from them, only from individual users who've had the issue. It seems like Revive should be publishing methods for finding such exploits, since they left the hole in the software that caused this.

I am shocked there is still no answer provided.

After reading this article it made my wonder if my installation in infected with malware, and if so, how can I detect it? Millions of web surfers are being targeted by a single malvertising group ­ Ars Technica https://arstechnica.com/information-technology/2021/04/malvertisers-use-120-hacked-ad-servers-to-target-millions-of-web-surfers/ To me it seems like you should have alerted anyone running your software of this problem, and sent out tips for how to find an infected installation, and repair it, but, it's not me running your business. Please share how to search for a compromised installation and disinfect it.

Update, I am able to get the link to at least function with the changes below, but notice the destination URL is very different from what is generated by the zone. In the code above generated by the zone, the link does not work: <!-- MySite.com Advertising No Cookie Image Tag - Generated with Revive Adserver v5.2.0 --> <a href='https://www. MySite.com/adserv/www/delivery/cl.php?zoneid=397&campaignid=1131&bannerid=2539' target='external'><img src='https://www. MySite.com/adserv/www/delivery/avw.php?zoneid=397&amp;source= MySite.com&amp;target=_blank&amp;cb=INSERT_RANDOM_NUMBER_HERE' border='0' alt='Gluten-Free Mall' /></a>

After the same upgrade my click tracking and links used in my eNewsletter no longer work. I re-created a tag which looks like this: <!-- MySite.com Advertising No Cookie Image Tag - Generated with Revive Adserver v5.2.0 --> <a href='http://www. MySite.com/adserv/www/delivery/cl.php?zoneid=397' target='_blank'><img src='http://www. MySite.com/adserv/www/delivery/avw.php?zoneid=397&amp;source= MySite.com&amp;target=_blank' border='0' alt='' /></a> However, the link does not function, even though it is correctly set up for the banner selected for this zone.

I am also having trouble creating links to track clicks in my eNewsletters. Has anyone found a solution to this issue?

How can I receive email notifications of updates to Revive? I just discovered that 5.5.1 is out with a security update, but never received an email about this. I thought I was on the list, but apparently I'm not.

So, the important test I did was that it works fine using Iframe tags, but will not work at all using the async tags. Do you know why that would be? Again, I've tried everything, and to me it seems to be some sort of coding issue with the async tags.

So I can get the iFrame tags working as described above, but not the async tags. Do you know why the async would not work for a subdomain, while the iFrame tag would?

Perhaps I am misunderstanding what Delivery Engine URL means. Is this the web site where the ads are served? It isn't clear, but knowing this might be helpful?

When I change the Delivery Engine URL (SSL) to the subdomain ads.mydomain.com the banners stop displaying. I can only get this setting working when it is www.mydomain.com. Normally this would make me think that the subdomain isn't set up properly, but it is, as I use it to server other content on the site (for example Google Analytics). I also mentioned that I am using the subdomain to server the asyncjs.php script in the site template, and I am using it as the Image Store URL (SSL) setting. So, the subdomain is set up, working, and there is nothing in my .htaccess, site security policy, or anywhere else on the server side that seems to be causing this issue. I will take another look at the troubleshooting guide, but I did look at it last time I brought this issue up, and saw nothing that would explain this.

I brought this up once before, and I still cannot solve this issue. I would like to change the setting for "Delivery Engine URL (SSL)" to a subdomain, for example ads.mydomain.com. But when I do this the ads do not show. It only works using www.mydomain.com. This is strange because I can change the "Image Store URL (SSL)" setting to ads.mydomain.com, and it works fine. I can also use this path in my site's template, and it works fine: <script async src="https://ads.mydomain.com/adserv/www/delivery/asyncjs.php"></script> There is nothing in my .htaccess or site security policy that won't allow this to work. Any ideas?

So in root .htaccess is being read and executed, and I do have that code in there for force cookies to be https, yet it does not work.

I was finally able to upgrade to 5.0.5, so whatever issues may have been present in the earlier versions that I tried to upgrade to seem to be fixed in the latest version. My database correctly upgraded.