Jump to content

motowebmaster

Approved members
  • Posts

    32
  • Joined

  • Last visited

Everything posted by motowebmaster

  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?
  16. I change paths and filenames as well, but admit that it is largely inneffective when serving adsense through revive. Adblock can see that being done and block adsense anyway. My modifications are effective on my direct advertisers. I rename the revive directory to a single letter and subdomain, in a format like this: http://m.domain.com/m I've also changed it up using common words in my websites, such as: http://motorcycle.domain.com/cruiser What I've done instead is implement an block-detector strategy instead. The problem is that some users are running noscript blockers, which is an attempt to block both ads and javascript; in either case, my site displays a randomly-placed "problem" notification (only once per day) that the user can close themselves - this strategy alone has boosted revenue. My innvocation code is a self-modified version of the single-page call, designed to establish all of the suitable ad sizes for a page using a single media query, so that I can serve a variety of ad sizes responsively. This used to be effective towards adblock, but now has the benefit of being merely "lightweight". In the end, there is no magic bullet, but hope this helps.
  17. I had the same problem during tests of installing revive as a subdirectory on an existing test-site, turned out to be a cookie issue but didn't take the time to figure it out. Went back to doing revive on a separate domain with its own dedicated IP address.
  18. Your file permissions for revive need to match those required by your webserver, not the database username. When you look at the ownership of your Wordpress files, do the revive adserver files appear the same?
  19. Wouldn't you just change your innvocation code to https ?
  20. I'm interested in a suggested Digital Ocean droplet size for a Revive Adserver that does 10k impressions per day, it isn't incredibly busy.
  21. I've moved openx/revive many times, but only between servers using the same configuration. Usually to take advantage of faster hardware or data center. When the configuration isn't the same, as I'm testing now, I setup a new domain and manually move the clients/ads over when it is ready to go production.
  22. It did match, but thanks for responding. In the end I believe it was some sort of mysql issue, but couldn't figure out what the bug was. Took down the server and am going to try again this weekend with an alternative config.
  23. I'm trying to setup maintenance.php on a new server I'm trying out and see this error at the command line: PHP Fatal error: Call to a member function query() on a non-object in /<path removed>/lib/pear/DB/DataObject.php on line 2365 #!/usr/bin/php -q in the Debug log: Oct 11 13:49:57 -0400 OX-54396dc4f28fa [ warning] DB_DataObject-&gt;table: Inv alid argument supplied for foreach() on line 109 of &quot;/<path removed> server/public/motorcycle/lib/max/ErrorHandler.php&quot; on line 894 of &quot;/<path removed> server/public/motorcycle/lib/max/Dal/DataObjects/DB_DataObjectCommon.php&quot; on line 866 of &quot;/<path removed> server/public/motorcycle/lib/max/Dal/DataObjects/DB_DataObjectCommon.php&quot; on line 1890 of &quot;/srv/users/serverpilot/apps/a dserver/public/motorcycle/lib/pear/DB/DataObject.php&quot; on line 148 of &quot;/<path removed> server/public/motorcycle/lib/max/Dal/DataObjects/DB_DataObjectCommon.php&quot; on line 93 of &quot;/<path removed>s erver/public/motorcycle/lib/OA/Preferences.php&quot; on line 377 of &quot;/<path removed> server/public/motorcycle/lib/OA/Preferences.php&quot; on line 55 of &quot;/<path removed>s erver/public/motorcycle/lib/OX/Maintenance.php&quot; on line 48 of &quot;/<path removed>s erver/public/motorcycle/scripts/maintenance/maintenance.php&quot; on line 22 of &quot;/<path removed>s erver/public/motorcycle/maintenance/maintenance.php&quot; This is a new server configuration I'm testing, it isn't production yet. What am I missing?
×
×
  • Create New...