Richard Foley

The script tries to use "LOAD DATA INFILE ..." because it's faster. If it can't (for any reason) do this, then it falls back to using standard SQL INSERT statements instead. There is effectively no difference except from a performance perspective. Remain calm

Never mind (slaps head)

I have an insert which is failing in lib/pear/DB/DataObject.php here: $this->raiseError("insert:No table definition for {$this->__table}", DB_DATAOBJECT_ERROR_INVALIDCONFIG); return false; Never mind about the source of the error for now, I'm working on that (fixed). The issue is that I didn't see this error until I hunted it down by cut and destroy. The code in question returned false and continued otherwise silently. So, my question is whether my config is insufficient to call attention to this error, or is something else going on inside Revive which stops the error from being propagated out. In my php.ini I have, although nothing appears in the apache error logs, or in php_errors.log either: error_reporting = E_ALL display_errors = On log_errors = On error_log = php_errors.log In my Revive config I have, although nothing appears in the var/debug.log (and yes, it's writable). [log] enabled=1 type=file name="debug.log" Following dumping information manually to screen, I found the DB_DATAOBJECT_ERROR_INVALIDCONFIG call, however, without this: Nothing appears on screen, or in any logging/debug file. Excuse me for showing my ignorance, but perhaps there is a simple flag I'm missing, or someone has some helpful pointers here...?

Hey Andrew, a magic wand might help, or maybe even a big stick. Hmm, well, failing that, I'd volunteer to help set up some kind of worthwhile feedback mechanism here. As I'm not a core developer I'd not be taking time away from your core functionality. If you want to grow your team, and I can help, please let me know. Cheers.

Got it. Remove the offending language files (*.mo + *.po) and repackage the zip using the script provided in the directory. It's not that complicated

You can apply the single banner delivery limitations to "all banners in this campaign" via the action popup. That might work for you?

Thanks for sharing your knowledge, Umarizal. (y)

Does nobody have any ideas how to install the Toolbox, or is the question just too simple to be worth answering?

Having trouble installing the Toolbox, from inside git cloned plugins_repo/ using a clean 3.1.0 $> ./package.sh openXDeveloperToolbox -r $> file *zip openXDeveloperToolbox.zip: Zip archive data Navigate to: www/admin/plugin-index.php, locate zip file and click "Install": 56 unexpected files found /plugins/etc/oxPlugin/_lang/ja.mo /plugins/etc/oxPlugin/_lang/tr.mo /plugins/etc/oxPlugin/_lang/hu.mo ...<multiple lines snipped>... /plugins/etc/oxPlugin/_lang/el.mo /plugins/etc/oxPlugin/_lang/it.mo /plugins/etc/oxPlugin/_lang/ko.mo The uploaded file did not pass security check The uploaded file openXDeveloperToolbox.zip was not unpacked Presumably I'm doing something simple and wrong here? Any helpful suggestions appreciated.

For reference, the 4 modules, (you can't call them plugins), I purchased here have a current total of 25 obvious show-stopper bugs/errors. No idea how many are still hidden behind the rest of the obfuscation waiting to jump out and bite the unwary. Current state of fixing the errors status is intermittent at best. If the code wasn't obfuscated, I'd fix the damned things myself and be done with it, oh, the joys of using closed-source code...

Maybe the openX API docs. here help? http://docs.openx.com/api/#about_topics_api.html

Revive also has a very useful click-rate setting which can help reduce fraudulent repeat clicks: http://www.adserveropenx.com/how-to-preventavoid-fraud-clicks-in-openx/

Thanks for that, Erik, you're right. (thumbs-up)

This is NOT a rant against Revive. Revive has what appears to be a solid, well tested, codebase which people can extend using a clean plugin interface. I am talking here about available plugins for common, and lacking, functionality in the core. Simply, I'm trying to extend a Revive installation to handle advertiser billing, and advertiser/publisher registration, and publisher revenue share, and so forth. You'd think this would be easy with an ADs server. I've now tried 3 different plugin providers (the only ones I can find which offer any kind of plugins to do the job). I'm NOT going to name names, here, as I think that's counter-productive, but I am going to post a couple of examples to demonstrate the kinds of problems we (as end users) are up against, and which the Revive community could perhaps consider addressing. 1. using short php tags: [php5:error] [pid 8509] [client 127.0.0.1:60745] PHP Parse error: syntax error, unexpected end of file in /home/adsman/revive/www/admin/account-settings-banner-approve.php on line 125, referer: http://srv.localhost/www/admin/account-settings-plugins.php https://kovshenin.com/2012/reminder-dont-use-the-short-php-open-tag/ 2. Installation instructions in one module say to apply "SQL.sql" against the database and in the next module it's "sql.sql" 3. Installation instructions in one module say to copy all the files manually from the "lib-OA/" directory into "lib/OA/", and in the next module it's "lib_OA/" into "lib/OA/". 4. The descriptions, and instructions, are written in such poor English, it's very difficult to tell one product from another, or even precisely what their functionality actually is. It doesn't matter where you come from, *everybody* knows you need a "native speaker" to proof-read the final for-public-consumption documentation. This is also discussed here in the following link. http://forum.revive-adserver.com/topic/542-billing-and-payment/#entry4158 Eg: You may registerd with us after this period. Eg: in right top corner you can able to see “Working as” ? click it Eg: Upload below files with respectively attached file in”lib/OA/Admin/Menu” folder. There's just no need/excuse for this. 5. The modules are not coded as plugins, (to be installed using the existing Revive plugins import functionality), but instead one has to copy the file across manually, leading to unreliability and potential copying errors. 6. When the files from one module are copied over existing files which another module happens to use, the functionality from the existing module is (obviously) lost...! There appears to be no understanding of the distinctness of the term "modular". 7. There seems to be no concept of testing code, or QA against user experience. The items above may even be quite acceptable to script kiddies or apprentice programmers, (clearly they are acceptable to the devs and their managers), but, imho, this standard of quality is indicative of sloppy work crassly implemented by people who couldn't care less. and so it goes on. So, this rant is concerning plugin providers who "provide" badly described, under-documented, code which, when installed manually (because automatic is unsupported), destroys existing functionality and leaves a broken system. The end user is expected to "merge" these files correctly, such that the intended operation is restored, even though the code is of such a high quality that it is "protected" by obfuscation, making any sensible debugging approach quite impossible. I've purchased 3 or 4 modules and have lost count of the number of (quite unnecessary) bugs I've reported. Now, you might say to me, "code it yourself then". Well, yes, and I intend to improve my PHP such that I am able to sort some of these problems out myself, in the future. In the short term, I have to rely on plugin "providers" who do NOT do what they say on the box. In the long term, what do we expect to happen when the payment intermediary (paypal etc.) changes their protocol and module support is requested from the existing providers based on prior experience? I'll say it again: I LIKE Revive!, it's largely a very tidy codebase, (with perhaps a little bit of cruft here and there, but who's looking). Revive is great, open-source is great. The *available* plugins facilitators appear to be a very different breed. If I had any hair left, I'd pull it out. Rant over.

Here's an interesting discussion on "Ad Selling: Click vs Visits Discrepancy" https://www.linkedin.com/groups/Ad-Selling-Click-vs-Visits-2967.S.5928060095282839552

Revive is an open source platform. Not sharing this information just makes more people suffer from the problem. Look at how ssh works in open source development. These tools are openly discussed. How about instead of saying "choose not to disclose", we discuss the issue in open forum, so that we can benefit from each other and make our filters stronger? I'll put my hand up and say I don't have any filters in place yet, but would welcome advice from more advanced user/devs as to where to start to address this serious issue.

Is there a procedure for requesting a specific hook? eg; in plugins/invocationTags TIA.

@csaelz Yes, we can use this at the time of invocation code generation. document.write('&amp;AdCategories='+AdCategoriesValue); However, this is a very clunky manual step for this otherwise smooth software. What we really need is a simple field on the Tag Settings page/tab, where you can simply add "site or zone variables". "&x=y&foo=bar&so=on". That this does not exist, (unless I've missed this feature), is crazy (imho). Cheers.

Yep, Erik, that would work just fine, too. Roll on the future

There appear to be a few people providing plugins for Revive. However, it's not often clear which people / company are still extant (operational) and which are even compatible with the latest released version/s. I do NOT mean for development related posts, I mean a forum which is dedicated to resources information. Might I suggest the creation of a new forum which is explicitly ONLY for posting of links to the websites of active Revive developers and similar services? At the moment, the list would seem to include the following for Plugins: http://www.adserverplugins.com/ http://www.reviveadservermod.com/ and for Hosting: http://www.reviveservers.com/ There may be more, but we (as the user base) need to what/who/where they are. Cheers.

1. yep (fixed). 2. yep. 3. yep, I posted this before I realized RevMax was unrelated to Revive, (just FYI). I also notice that RevMax is unsupported now. 4. If you want to remove the post as 'non-relevant to revive', that would seem reasonable.

One of these modules looks like they may to the job: http://www.reviveadservermod.com/sign-up

You'll need a plugin, something like this, probably: http://www.reviveadservermod.com/sign-up/self-signed-user-authorization

I have it on reasonable authority that the RevMax plugin is no longer being maintained.

https://github.com/revive-adserver/revive-adserver/blob/master/plugins_repo/openXDeveloperToolbox/plugins/etc/openXDeveloperToolbox.readme.txt Refers to non-existent URLs: https://developer.openx.org/wiki/display/COMM/Plugins+for+2.8 https://developer.openx.org/wiki/display/COMM/Plugins+2.8+-+How+to+create+a+schema+for+the+demoBannerTypeHTML+plugin Update with relevant URLs, please?