Similar to how you can set custom meta keywords and description for an IPC page, it would be nice if there was a field to add specific content to add to the HEAD section of the page as well instead of having to use a raw php page.
Well, it's been a year since FedEx shipping was added to nexus.with the promise of more to come it the future. It sure would be great to see IPS deliver on those.
With one API already written, it certainly wouldn't take much work to extend that to other popular carriers like USPS that offer great international shipping options that are easy to use for the small business that doesn't ship enough to get volume discounts from FedEx.
I got it working on 3.3.4, however the problem is the hook now affecting the meta description and meta keywords of the page. Any content you have in the advert is also being passed to the meta description and meta keywords for the page as if it was part of the first post content.
Most large sites use a 3rd party ad server. Nexus is great for the ad locations, but having the constant update queries to run the impression counts are extra DB calls that aren't really needed when you're running a 3rd party ad server (or even if running straight adsense ad code).
There should be an option for each advertisement to enable/disable impression counting. This would save a whole lot of writes to the database for sites that don't need the impressions counted for them in Nexus.
Being a forum admin of a 10,000,000 post site. The archive in theory is a great idea.
However, I have to agree with mikesound on this one.
The entire reason big sites run things like sphinx is to keep searching of a large database fast.
There is really no reason I can see to not take advantage of the power of sphinx and the archive feature together.
Sphinx can eaisly handle a single result across both the live and archive tables. I can't speak to using mysql full text search (since I stopped using that 9 million posts ago). But for a sphinx search setup, it should absolutly search the archive and live posts at the same time. There's just no downside to doing it that way.
The z-index on user menus and hovercards needs to be increased.
By default, all rich media ads served by double click (this is what is used for serving rich media adsense ads) have a z-index of either 999999-1000000. See here: http://support.google.com/richmedia/bin/answer.py?hl=en&answer=1249219
Since adsense/double click is the #1 ad network, and the most like ads to be used on a forum, it would be good practice to increase the z-index used in IPB for menu's and hovercards to be higher than than 1,000,000.
Yes, I agree that is an insanely high number, but since we can't control what google does, we can at least compensate for it.
For example, if you use the standard ad slot on the mobile skin for the top of the page, you can't click the sign-in button on the mobile menu because of the z-index being use by adsense.
This is a wonderful feature, and one that saves me some work too since it was already on our own internal road map to build.
I would like to offer a suggestion since you've already done the heavy lifting.
Auto-share on posting is a great place to start, but if a user likes a topic enough to "follow" that topic, that would also be a great place to auto-share. Either as a per-user settings option or through a couple of check-boxes added to the follow notification layer.
Auto-like is another great addition. If a user like's a post enough to click "like this", why not also auto-like that post on FB as well. This could be a per user on/off option in the "Manage Facebook" settings page.
Any thing you can do to add content sharing directly in the user's normal workflow will only serve to grow your community.
There is a plugin for vbulletin 3.X series called vbouncer.
It sets a return path for all emails sent out by the forums, then using a cron job checked that email for bounces daily and can take different actions such as turn off all email notifications for a user, or set them back to unconfirmed status depending on the number of bounces received in a specified time period.
I've used it for years on many different server configurations, and it really works very well. I would think it can't be that hard to port over to IPB.