Jump to content

Search the Community

Showing results for tags 'rant'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Using and Managing Revive Adserver
    • Documentation
    • Using Revive Adserver
    • Managing Revive Adserver
    • Bugs
  • Advanced Topics
    • Performance, Scalability, and Reliability
    • For Developers
  • Revive Adserver Community
    • Revive Adserver Project News and Announcements
    • Feature Requests
    • Plugins
    • Requests for Consulting
    • Off Topic

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL

Found 1 result

  1. 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.
×
×
  • Create New...