Fast Lane!

How limited are the ad placement options now? I can’t insert code into templates anymore? We even have conditional code to do things like add ads after the 1st and 7th post… etc. What about adding code to the page header? Example for AdManager and preview there is tons of code that must be there in addition to the ads themselves. Should these new limits stand to reduce income generated by our forums — that feels like a golden goose that should not be touched.

Sure. Whatever works for your use case. For me the incredible level of microtargeting and backfill inventory from AdX and Adsense when you don’t have 100% direct sales of your inventory, more than makes up for this.

You could use a direct sale banner created in Google Ad Manager and serve it via IPB. Compare the two. GAM should be a gold standard in terms of measurement, as I mentioned. This will give you some confidence.

Just out of curiosity on feature focus and deprecation. Why does IPB support a built in advertising solution when Google Adsense and AdManager are free? They are the gold standard. IPBs ad section could simply be downsized to focus on allowing insertion of ad units at specific locations for specific users and rulesets instead. The actual adserving and tracking could be shifted back to Google. Thoughts?

Thanks Matt for setting the record straight :). I was seeing some confusion. Hopefully a 3rd party solution will come along.

The upgrade will delete this user generated content...? We have "a few" status updates that would get removed.... terrible :(.

Some use cases we use that should help me understand what is possible. We have 50-100 blocks that fall into one of these categories... 1). We use a php command to import html into an IPB block (for us, we use an external php script to generate different html content throughout the day via a cronjob... dumping to a flat file). Example in a custom php block: readfile("/home/m/public_html/tools/popular_topics.txt"); 2) Can we execute php in a block to tailor what is shown to a user based on information from a non-IPB database? Example: $member_id = ''; if(isset($_COOKIE["mm2_member_id"])) { $member_id = (int) $_COOKIE["mm2_member_id"]; } if ($member_id != 0 && $member_id != '') { //check a different non-IPB database to pull in data about a user, based on their common member_id // Depending on returned value, show different things to the user } 3) Can we execute full php code in a block (catch all question)? Seems no? We have soo many use cases here....

Azure CDN

This seems awfully similar (maybe the same) to what we experienced. Both of us had issues with an existing CDN with files breaking right after the .19 update. @Marc for thoughts if any. The root cause from what I can tell was with the 2 noted files having too many redirects and generating a 504 error. If it was a config issue I would have expected all files to break. Not just 2 very specific ones. Purging and refreshing those files didn’t fix it.

Some preliminary testing shows if I bypass my CDN and route that traffic directly back to my server for those items this resolves. It doesn't explain why 2 of thousands of files at the CDN are 504'ing. This happened immediately when I upgraded to .19. No change to CDN or server config. Wondering what redirect rules or other items may have caused this with .19. I really don't prefer to not have my CDN sitting in front of my site (for obvious reasons)....

So digging into browser debug data and server logs, I see that a 2 files (one css and on js) which are hosted on a subdomain and linked to a CDN.... are getting 504 gateway issues (time out / unreachable). Server logs show too many directs on those files. Did IPB change any redirect rule sets with this update that may have added an additional 'hop' which happened to put us over the limit? Not sure if this is the root cause at the moment. The files are: 97c0a48072ce601c9764cb6b00a6588a_page.css root_map.js Both are 504. Both are reachable via the folder but not the subdomain mapped to the CDN, as a 504 is generated when pulled from the subdomain. This started only after the .19 update. Given someone else saw this... perhaps there is an edge case bug here worth exploring?

6) I also purged my CDN end points to clear any items there that may have been cached. Issues still persists. 7) disabled 3rd party apps. Issues still persists.

Update: I changed the caching method to filesystem and can repro. Changed back to redis and can still repro. @Jim M any other thoughts? Debug so far: 1) Set Theme for admin account to default (unmodified IPB) and can repro 2) Changed caching method to filesystem and can repro 3) Cleared cache on support page of ACP and can repro 4) Completed restart of apache/php and can repro 5) Completed full server reboot and can repro

New reports have the same issue. I can delete them on the ticket view (that works). I changed the theme to the default unmodified IPB theme. Can repro. Could this be a redis caching issue?

On a report submitted before we updated. Let me check if new reports submitted after we updated work...