Jump to content

motowebmaster

Approved members
  • Posts

    32
  • Joined

  • Last visited

About motowebmaster

Recent Profile Visitors

1398 profile views

motowebmaster's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Was running on php 8.1 for a couple days, after re-linking zones to a website, and thought I'd had it solved - until it broke again. Ads disappeared from my desktop, but we're still showing on my mobile. Resovled it by going back to php 7.4 So I thought I'd check out the innvocation code, to see if I needed to update something, and went down a rabbit-hole involving the deprecation of single-page-call. Someone could have said something ?
  2. Ads went away again. Had to switch back, to php 7.4.28, in order to restore them ?
  3. An update. Upgraded to 5.4.0 and switched to php 8.1.4 earlier today. Seems to be running well with php8, ads don't dissapear. Regarding the file cache, there is still one file being written with root permissions and full write/execute (chmod 777). It is being placed outside the normal document root and being replaced at the configured cache interval with the other cache files, so it should be safe, but would prefer that it be written with the same user/group ownership of the other files in the cache directory.
  4. Guess I spoke too soon, had to switch my revive adserver back to php 7.4.27 in order to restore normal operation. It's like the server wasn't responding to the single page call at all, after it had been working for a day. I noticed something the night before, but it was happening only on my desktop PC ads weren't working - but they were on my mobile - from the same network. Wanted to see if it would resolve itself, but ads ended up not running for anyone. It will likely work if I switched back to php8, but don't know what to look for. A response would be appreciated.
  5. So after 20+ Hours: The delivery cache looks clean. Just one file being written with root user ownership, group ownership is correct. Appears to be a php file associated with the maintenance routine, but since the entire delivery cache is now being written outside the document root I suppose it isn't critical. It is being updated every five minutes. The files in /var/cache are being written with the correct user/group ownership. Even with me navigating the admin interface they aren't being updated. I put an empty index.php file in that directory and gave it the proper ownership/permissions. No files are being given root ownership for unrestricted permissions. I still have GZIP disabled in the user interface settings, but am thinking that my webserver (Litespeed) may be doing some compression anyway. I have LSCache disabled, revivie started exhibiting issues with LSCache a couple versions ago, but haven't disabled any Litespeed compression settings. I am running AlmaLinux, migrated from CentOS8 using AlmaLinux' migration script, but don't think it is relevant. Hope this is helpful. I still don't know why ads failed to work on the first day. I'm assuming that php 8.1 isn't supported yet, but am able to switch to it if my assumption is wrong. Thanks for your efforts ?
  6. Ok, learned something; Moving the banner delivery file cache out of the document root works Changed the banner cache update interval from 1200 to 300 seconds, it is updating properly The files in the banner delivery cache are being given the proper ownership and permissions The admin file cache is still being written to the default /var/cache directory Shouldn't all of the cache files be written to the custom location I've set for the banner delivery file cache? If it isn't supported, can there be a config option added where I can set a custom location for the admin file cache that also supports a permission validation and update interval? I've made a couple "restrictive" PHP parameter changes, but it caused problems. When I put the php settings back, and restarted the webserver, the admin interface was still displaying errors. Changing back to php 7.4.27 fixed the issue, then I was able to switch back to php 8.0.15 again. During that experience a file with root ownership was written into the banner delivery cache directory, so I cleared all off the cache files again. Initially was thinking that someone/something was attacking my file cache, but now think that it's a bug. The banner delivery cache now appears clean, being written outside the document root, and updating every five minutes. Disabled GZIP content compression on the user interface settings. Cleared the cache files again in /var/cache but wish they weren't there at all.
  7. Ok, had to clear the cache again because: Files were being written with the wrong permissions they were being given root ownership, which shouldn't be happening An error message was displaying within the admin interface, stating there was a problem with file permissions. I enabled debug log and it listed one file in /var/cache I'm going to move the file cache out of the document root, something I should have done already.
  8. Switched back to 8.0.15 again and things were running ok. So I manually-ran the maintenance items, checked the plugins, cleared everything in /var/cache, and restarted stuff. It's been running good for 12 hours. Thinking that clearing /var/cache helped the most. Some of the files in it were too old. Makes me wonder if I should setup a cron to clear the cache weekly. Cleared the cache again because one of the recent files had the wrong ownership/permissions.
  9. Attempted to switch from php 7.4.27 to php 8.0.15, and things appeared to be running fine. Came back to my site a few hours later and ads weren't working. Did some tests on my primary site, because I thought I had broken something after a minor update, then switched my revive adserver back to php 7.4.27 and ads started working again. Should I enable debugging in revive, or is php 8.0.15 a problem?
  10. I'm late to this party, but typically don't upgrade revive over my current install. I download the latest version to a new directory. There is an article that is similar to my process: https://www.revive-adserver.com/how-to/update/ It has some steps that I don't use, like making anything world-writeable via chmod 777, but still a good guide to study/adopt. The only two files I copy-over from my previous install is my config and a custom htaccess file that I drop into the admin directory. I don't use a FTP Program, do the majority of the steps at the command line - the rest in a browser. Plugins are updated from the previous install. When the upgrade is done I delete the previous version that I just upgraded from. The end result is a virtually clean install of the latest version. I re-apply a single line of code back on my actual website and all of the ads are active again.
  11. Yes, you need to change the actual filenames as well. I keep a list of tasks to be done with each upgrade, renaming the files at the command line is one of them. The filename settings in Revive Adserver should be retained with each upgrade. I've been renaming the files for years, but admit that it isn't 100% successful. It just takes your ad server out of some of the more basic blocking mechanisms.
  12. This is more challenging than I realized. My forum script, Xenforo, is responsive but there doesn't seem to be a way to write a template conditional that is linked to a media query.
  13. Instead of using: OA_Show(zoneid) I currently use: OA_Show(variable) I assign a variable to each of my five zone ids, then define a couple OA_Show variables, and do a window/width media query. Initially the default is ad sizes accommodate mobile phones. If the width is larger than either 500px or 800px I change a couple of the OA_Show variables to switch to larger ad formats. It is essentially a simplistic way to support my site's responsive layout design. The data-revive-zoneid appears to be the only unique value in any async tag. I guess that is what needs to change dynamically.
  14. Good to know. So I just do my media query and display the respective async tags?
  15. Hello, It doesn't appear see that Single Page Call hasn't progressed to the point of utilizing it with the async tag, but am willing to fatten-up my javascript a bit in order to improve response time. My single-page call code is simple. I set my variable names with the zone numbers, and then redefine a couple variables if the width is wider than two particular points. Then run the Revive Adserver SPC script, and display my variables within OA_SHOW in three places. The benefit is that I'm doing only one media query per page, and displaying all of proper the ad zones for that page. I'd like to think that sticking with one media query per page is a best practice, and the users could handle a bit more character download in return for a potentially faster experience using the Revive Adserver async tag. Any thoughts?
×
×
  • Create New...