We’re not happy with any of the supported by Discourse ad networks, but we have found one that works perfectly on our blog and we would love to implement it on our forum as well, however it requires us to copy a code and paste it within our site’s HTML. Where exactly do we do that and would it work?
Just use theme components to do that
1 Like
Thanks, but I’m not a developer. My knowledge doesn’t go beyond setting up a Discord (which took me a week) and changing site settings.
Then you can start form here
Your aim is to create a theme component, add the ad <script> to the /head tab and activate the theme component in your main theme.
When your theme component will be activated you need to whitelist the URL of your script following this
4 Likes
Welcome to the club, we are in the same boat. But, a quick heads up, this won’t work with theme components, so the suggested answer won’t work. We’ve gone down this path, as have others (see our topics on this). With theme components, the ad script won’t show in the body where it supposed to show. The commentator suggesting using script in the /head may not be familiar with how ad scripts need to actually be implemented. We tried theme components and couldn’t do it because there are limitations of what you can do with theme components.
Ultimately, you will need a plugin to do what you need to do to show from other ad networks. Unfortunately, no plugin exists for this yet. The only hope is that Discuss will add a generic ad script in the Ads plugin to support third-party ad scripts that need to be injected into the area of the ad. Right now you can basically only use Google DFP, but if you use another ad provider, you are screwed and can’t monetize the forum. This is unfortunate because there are many other good ad networks (e.g. Adbutler, Openx etc.), and you shouldn’t be forced to use Google DFP to serve ads.
Well here’s to hoping that Discourse will add a generic ad script to the ads plugin. I don’t particularly see why this is difficult to do, but honestly I have no clue on to program in Ruby and Ember, so I’m not sure how to do it. In theory, all they need is a textarea in the plugin that will accept script tags and then inject those in the ad areas the plugin already designates. Having a generic script box, as opposed to a box that will only accept straight up HTML, will take care of every single ad network basically, without the need to implement specific code for every single ad network.
2 Likes
Caleb, out of interest which service are you using on your blog?
1 Like
It’s kind of difficult to address your points without context. It would be very helpful if you can include more specifics about what ad network you’re referring to and how exactly it did not work for you.
That’s not entirely true and it really depends on the ad network you’re trying to use. If it’s a strict requirement that the script for the ad network is placed next to the </body> tag - which is unlikely - then it’s really the ad network’s fault for having such a strict and unreasonable requirement.
Scripts added in a theme are pulled into a theme.js file that is then injected in the <head> tag of the document.
https://github.com/discourse/discourse/commit/6acdea37c4e77723c774152e9076dfedda99493a
This gives us some level of control and allows us to implement some helpful features like preventing broken themes from taking down the entire site, for example.
https://github.com/discourse/discourse/pull/7589/files
This is also only partly true. Themes can modify anything on the client-side. What that means is that anything written in JavaScript in Discourse is accessible by themes.
In fact, the entire official ad plugin can be converted to a theme component and it would work. The only thing that would be missing is the ability to add a ads.txt file because that would require access to the back-end. The reason why we haven’t done so is because a plugin is a cleaner implementation for this purpose - namely because it includes more than one provider. So yeah, themes have limitations but that’s not really the main point here.
There’s a very important note here, Discourse is a single page application. This means that once you load the app on initial page view, all navigation that occurs after that is handled by Discourse and not your browser.
This is important to note because an ad network has to provide the hooks necessary for single page applications to update the page information and serve new ads. I don’t know much about Adbutler or Openx, but I couldn’t find any documentation for single page application support by either provider.
So, if the ad network doesn’t provide the necessary hooks, is it really Discourse’s fault that it’s not supported?
You aren’t really forced to use DFP. It’s only one of six options available in the official ad plugin and I’ll list them here for reference.
- DFP
- AdSense
- Google ads
- Amazon advertizing
- Codefund
- Carbon Ads
Again, because Discourse is a single page application, “generic” just won’t work.
Sure, you can load whatever ad scripts you want in a theme, but they would only fire on the initial page view. Anything that comes after that will be missed by the ad network script - unless the ad network provides the necessary hooks.
Here’s what such an integration looks like on an ad network that supports single page applications.
You do actually need to have specific code implementations for every single ad network.
Also, I think you’re mixing up house ads with ads from ad networks. The reason why the box is HTML only is because you’re supposed to use it to create your own in-house ads. It’s a very straightforward implementation that’s already been wired up in the plugin so that you don’t have to fuss around with single page hooks if you just want to serve your own ads.
Further, if you really want another ad network to be included in the ad plugin, then there’s precedent for us adding new ad networks based on community contributions.
The most recent example of that being the Carbon Ads integration
https://github.com/discourse/discourse-adplugin/pull/73/files
However, the burden to wire up everything correctly falls on you here.
If you find such implementation to be too tricky, then that’s that. I’m very competent at changing the tyres or the oil in my car, but if I need to service the transmission, then I just simply find someone who knows more than I do and pay them to do it for me.
What I’m getting at is that if you really want to use another ad network and can’t quite pull it off yourself, then I suggest creating a topic in the #marketplace and I’m sure you’ll get some developer’s attention if you have the right budget.
9 Likes
Thanks for your detailed response and help. There’s alot here to digest.
But, I think there is a misunderstanding here. AdButler is a type of Ad Server, akin to Google DFP. These providers help you manage your own ads with advertisers. Whereas things like Adsense (and Carbon apparently) are Ad Networks. Ad Networks work somewhat different than Ad Servers. Our issue is with Ad Servers, rather than Ad Networks. Sorry for the confusion.
We need to be able to make money from our website to stay in business, and to do so we need to use an Ad Server to manage advertisers. We use Ad Butler for this. The In House Ads functionality doesn’t even come close to what is needed. The only Ad Server supported by the Ad Plugin from Discourse, from what I can tell, is Google DFP. Google DFP is garbage, in my opinion, for various reasons, which are not relevant to this discussion. Of course, if we are forced to use Google DFP, because there is no other ad server supported by the Ad Plugin, well then we will, because Discourse has so many other benefits that it sort of outweighs the sheer annoyance of using Google DFP.
I fully understand that it falls to us to develop a plugin for another Ad Server other than Google DFP, and that Discourse can’t meet every single need, especially since it does so much out of the box that is just simply outstanding. We did submit this to the marketplace and some experienced coders with Discourse told us it could not be done without a plugin and the work was quite expensive and consuming, relative to what is seemingly a simple issue.
You are correct in that I have no clue how Discourse works yet, as we are just starting with it and learning Ruby and Ember. However, with Wordpress, for example, we drop the ad script from Ad Butler into a Widget box, and it just works. There is nothing to program. So I was somewhat surprised that getting something like Ad Butler to work with Discourse was such a hassle. I get that Discourse is obviously very different than Wordpress, and much more complicated, but I still don’t understand why something like this requires such heavy coding.
In sum, we will keep trying and will reach out to Ad Butler themselves to see if they can help. It will serve their interest for sure to help develop something for Discourse, as they may get alot of clients out of it (once you use Ad Butler you will never go back to DFP). We’ll also take a look at the Carbon Ads integration and try to understand how it works, as maybe we can modify for our needs.
Thanks again.
1 Like
Quick follow up, I did look at the code for Carbon Ads in the Ad Plugin, and I have a conceptual understanding of how this was done, so hopefully we can use this a springboard to implement Ad Butler. Thanks for the heads up on Carbon Ads.
3 Likes
No. We’ve contacted a few programmers, but nobody has given us a firm quote and timeline yet. In Wordpress we stick the code in a widget and we are done. We’ve been surprised at how complex some of the programming is in Discourse. Anyway, we will look a little more, so I’ll keep you posted. But we are leaning towards just moving to DFP, which is supported in the core plugin, even if we are really not happy to have to do this.
2 Likes