Dizkus

API-compliant file structure, perhaps?

Very good work on the list... as usual.

All of this has my vote.

:)



edited by: alarconcepts, Jun 24, 2007 - 07:54 PM

--
Photography | PHP | Other

I am trying to make a decision on this thread...

I am not sure of the why, it would seem to me that there would be an adverse effect on modules that are not 'certified' by some.

In the real world certification does not mean a whole lot. I build PCs mostly for Windows use. Let me tell you if I care if drivers are Windows Certified or not. I do not. But I would have to say, I have had more than one service on a computer whose user did not install drivers because they were not certified by windows... LOL. HA!

AutoTheme would be a great example of a module that would not certify. I can tell you, for having used AT for years.. that it is a great module, highly supported, regularly updated, well documented, ect... It works, it works well, it works consistently. It is a great product.

Hell, I could even probably code a module that would certify, but would have no real functionality at all, just to prove that I could write a certification compliant Do-Nothing module.

My point is that certification does not ensure the legitimacy/functionality/usefulness of a module. If someone codes a useful module, it is useful, where it is certified or not. So I guess I will have to start a my own certification "AmmoDump's Usefulness Approved" ...

I am not trying to undermine anyone's ideas here... just adding a different point of view to help fully develop the idea, if it is to come to fruition..



--
David Pahl
Zikula Support Team

Hi David

You are right - there are lots of good non-pnAPI modules that solves peoples problems ... and vice versa ... pnAPI modules that are plain useless A certificate won't solve this problem.

A certified module would tell you that you should have less problems getting it to run on current and future PostNuke installations = less frustration over technology issues. It says nothing about the usefullness of the module.

There's an important line between usefull modules and certified modules. The first is a personal subjective decision, the second can be measured objectively.

Please add your "AmmoDump's favorites" somewhere. I have found two threads where users present their favorites and I find these postings rather usefull (http://community.postnuke.com/module-Forum-viewtopic-topic-33947.htm and http://community.postnuke.com/module-Forum-viewtopic-topic-52064.htm). The problem is always finding them again. That's why I have allowed myself to add them in the Wiki (http://community.postnuke.com/Wiki-BasicsContent.htm). Please add yours to the list.

As you can read then I prefer calling your module list "favorites" as opposed to "certified". How would you for instance describe the certification process of your, favorite, modules?

So - lets get more lists of favorite modules and then add certification on top of these ... that is, if anybody actually want certification. Because my guess is that most people will prefer the favorites lists

yeah - we've something quite similar in our german community - the **modultipps** - these are modules that are used by the german team and therfore well-known for support and specific problems

regarding the term 'certified module' - this has been discussed a couple of times before - but from a developer point of view i must say that it is almost impossible to run a complete auditing for a module that is currently under development from the 'outside' (at least as long as nobody is willing to pay for this service...)

--
regards from germany
..::[Zikula Application Framework]::.. ..::[SEO-Blog]::.. ..::[CMS Sicherheit]::..

I, for one, think certification is a great idea. The one problem I see is related to larsneo's latest comment... who will review these modules and make them officially certified? It seems that you'd need at least one person on it full time (or maybe a team of 3 or something), at least at first. A full checklist would need to be made and each module would have to be tested.

But I do think there's good things to come of this. Having a certification process would give PN a more professional image. I also think it would show that the PN team cares about the quality of the code itself as well as the user experience. It seems like a big task to take on, but IMHO one that would do wonders for the PN image.

--

All great comments...glad to see this inspired some discussion.

Certified modules would (IMHO):

1. Raise PostNuke's professionalism
2. Alleviate concerns of bad coding/security in certified modules
3. As people use certified modules, lessen the continued support issues dealing with outdated and badly coded modules that come up so often in the forums.
4. Appeal to businesses and others who are concerned about security (hey, the core might be great, but if a module doesn't have best practices, the security of the core is moot)
5. Appeal to those interested in a "base" level of functionality and coding standards expected of a certified module.

As for "who" certifies? And costs / time to certify? An idea...

1. PostNuke sets up the cert criteria - great list in this post by JornWildt!
2. A database of modules (hey! we already have that ) then allows for reviewers to grade the module to the cert criteria (1-5, 5 best, boolean on some, etc.).

Initially, maybe only the developer provides an initial cert. Others, after reviewing, could offer their own. If someone (business, or end-user) wanted an independent cert, they could pay someone proficient to provide a cert. Each modules could display a "peer" cert score, and an "authorized" cert score. Cert areas left blank are ignored (in case someone has no experience in security, but wanted to cert the templating and install functionality).

PostNuke then could merely identify potentially proficient certifiers (forum expertise, demonstrated coding ability, etc). Others could cert, but users could see if the certifier was "certified by" PostNuke

Load to postnuke: Only to reward proficient certifiers with that status, maintain cert criteria, add.
Load to users: None, unless wanting an independent cert and paying for it.
Load to developers: None, unless wanting to self cert or ask/pay a 3rd party to cert.

Lastly, Postuke foundation could benefit if there was a way for paid certifications to give back a certain percent in support of PostNuke, or PostNuke was a clearinghouse for paid certs - ie, module user negotiates with certifier, pays fee to foundation. When cert is done by certifier, 80% paid to certifier, 20% to foundation for supporting PostNuke.

Cons: certs could be "spammed" by users not qualified to really judge a modules criteria, non-cert modules may still be great modules, just no one took time to cert.

Pros: Average joe certs lend some credence to modules, "authorized" or "certified" certs lend better credence. Users have more info on modules. More motivation to developers to code to the certs criteria.

Thoughts: Many end-users probably would like to see modules certified - I would, save me time doing it myself to test and check security, and avoid poorly coded modules (like my own! lol).

Perhaps paid certs could be on a "pool of users" basis. Pledges to perform a cert are placed until the incentive is enough that someone takes the time to certify the module and collect the incentive.

Open source software, but offering services and security model with some kickback to the foundation to support further development.

NCM
UHEweb

[devils advocate]
Add this potential pitfall:

I can see where a module get a lot of credential from being around for a long while it gets a high rating....

Along comes Johnny competing module, Johnny doesn't care about certification, in fact his fist implementation of the new module are less than stellar. His rating is low... but one day Johnny gets inspired and rewrites his module and it is great. At the same time the other module has been abandoned, an security hole is discovered, the coder had triples and his home was attacked by wild monkeys. Now we have a scenario, where the bad module is better and the better module is worse.... I hope you see where this is going... And on top of it all, the certification project has been abounded by most of its certifiers...

[/devils advocate]

--
David Pahl
Zikula Support Team

The certified can have a sufficient time of renewal, so, if this module isn't supported anymore, its cert caducates, and the new rewrited good module, have now a best rank!...

--
- Mateo T. -
Mis principios... son mis fines

Wouldn't a well-certified module let it age well? If secure via coding standards, and API compliant and templated (just as a start) it should age well within the PostNuke framework.

Un-certified, non-compliant or low rated modules suffer with every PostNuke upgrade. They're not API compliant, they usually have security problems (register globals, etc), they fail to work from one version to another of PN.

So, in the above scenario, the well-certed module is well certed BECAUSE it hsa the features that make it a good module over time. If the new module has more features and was flashier, but had TERRIBLE security and API compliancy - meaning it would have serious problems as it aged, then certs ratings would keep people on the OLDER, YET STILL MORE certified module.

The new module developer would need to clean up their code, not just have something flashy, for a good cert.

Anyone can make a flashy, quick module. Certs would help show that modules that are consistent, well-coded and therefor have a longer PN life with fewer problems as PN matures and moves forward.

Look at all the people still trying to install and use mods from .726 days. Half the mods don't work, as they're all non-compliant and pieced together. But, they're still found as "PostNuke modules". With a cert list, some of the effort and community support time would be channeled into newer modules that are more in tune with the PostNuke core and future functionality.

In your scenario, a well-certed module abandoned also would be an item that many would take over, if they knew a strong code base existed and it was PN-compliant in many regards.

I'm not saying certs will be a miracle pill...but I think more info in the users / developers hands to create and use great modules for PostNuke will help.

As it is now, a new user comes here...gets PostNuke...downloads a module from 4-5 years go, has horrible problems getting it to work...then goes to Joomla, and never finds out that a new module exists that is up to current PostNuke standards.

NCM
UHEweb

This has been true in my experiences. My first module was pretty shabby, but it still works with Legacy Support enabled. :) Once I got the hang of the pnAPI and templating a little better, all subsequent work has aged well in terms of "still works as intended". If the developer uses the *Util methods and the basic pnAPI functions (and templates the output), s/he is well on the way to having the work age gracefully. This doesn't speak to security at all, but does offer much solace for the end-user at site/module upgrade time.


--
Photography | PHP | Other

Another aspect of certification might be some basic level of code commenting, such as is done in the core code. A small code block documenting each function doesn't take too much time usually, and really helps for devs who might later pick up the code or jump into the project mid-way.

:)

--
Photography | PHP | Other

Well I would like to know why there is such an emphasis on pnAPI compliance. Frankly I am hesitant to code anything using pnAPI or any other standardized system apart from my own. I prefer control over my code as opposed to having it "locked in" to the PostNuke framework. My future deployments will not use any libraries or API from PostNuke, they will be lean and portable.

Does this mean my code is inferior? It will look like it if there are big red "non-compliant" messages all over the place. I understand that customers would like this system, but really, IMHO, it is just giving another hassle to 3rd party developers, and frankly we have had enough hassle from this project and others over the years. It's good to look after your 3PD, as you can see you don't have much without them.

And in regards to non-gpl commercially licensed code I don't think any 3PD are going to give you there source to look at. I know that I won't.

-Lobos



edited by: Lobos, Jul 01, 2007 - 08:17 AM

--
-Lobos
Professional PHP Framework Services: Concept, Development and Deployment

Lobos,

So your code does not use pnAPI calls? Do you poll the database directly for data that resides in tables outside of the module?

The original idea was to help PostNuke be a place where users can find and quickly evaluate modules and their workability. Many of the problems people have with PostNuke are due to ancient or badly coded modules. They can't force module X to do what is used to do with PostNuke pre .750, so they abandon PostNuke.

As PostNuke becomes a pure core, good modules will need to flesh it out. The PN team can support good module development via a certificatation process without needing to maintain and adopt all 3PD's code. Users then gain insight into which modules work well with PostNuke, and overall satisfaction rises and PostNuke's user base grows and fewer abandon it as a platform.

Surely, no code would NEED to be pnAPI compliant. But if its not, and PostNuke changes somewhat, a pnAPI compliant module will still make the same call, and receive the same answer from the core. The module will still function. A module not API compliant could then be broken if not maintained 100% by a 3PD to adjust for the new DB structure, method or PN function that changed.

If someone wants a module that is abstracted from PostNuke, and usable in other CMS's, that's a selling point right there IF that's what someone wants. It's a trade off that some users might like, and others would like to know that its not API compliant and therefore perhaps in danger of being broken by future PostNuke updates. As a developer, if a module is non-API compliant, why not sell the point that is CMS independent?

How many other "modules" have there been that were nonAPI compliant, and now have gone by the wayside? Yet users still find them, try to get them to work, and they don't with the new PostNuke flavors. Certification would direct them to newer, API compliant modules UNLESS THEY HAD A DESIRE for CMS independent non-compliant ones

There are always trade offs, I don't see how more information in the hands of user would hurt.

Personally, if I was coding cross-CMS modules, I'd have the module logic seperated by an API layer. Joomla API, PostNuke API, etc. Then, it could be compliant with each and every CMS while having the core module logic abstracted.

Making direct calls to the database in any CMS is always in danger of breaking the module if the base CMS changes. Users should be told such (API compliant cert or not) - informed users, are happy users.

JMHO

NCM
UHEweb

this is a very interesting thread. Ok, but what is the true incentive for getting a module certifide? how about this, I was just messing with gallery from melinto(sp?) and they have a module to download modules from the main site. This would be a novel idea for PostNuke. This cert would ensure the security, yet availibity for the modules use by the system itself.

Silver.

Thankyou for your feedback.

The current system I have in place only needs the following variables from PostNuke (or any other web application for that matter):

username
userlevel
systempath
database: type, username, password, name, etc

This is all declared in a simple file and it is just a matter of supplying this file for compatiblity.

I have my own advanced OO framework as well as an advanced permissions system. If upgrading somehow makes my system incompatible it will also make all existing modules incompatible as well. In fact my system has more chance to maintain compatiblity thru multiple versions than an actual pnAPI compliant module.

I have learned a lot over the years from sniffing around in the code. I now have a good overview on what it takes deploy next generation frameworks / web applications and I am in the process of fine tuning this as we speak.

-Lobos

--
-Lobos
Professional PHP Framework Services: Concept, Development and Deployment