Just having one of those nights where one can't sleep and my thoughts turned to my sites and I'm startung to wonder where I can go in the future using Postnuke on my sites.
I've only been using PN a couple of years and I have seen some great developments in that time but now I'm not too sure that all of those have been good.
It seems that with each new release of Postnuke, I lose some functionality from a site - simply because the module developers aren't able (or aren't inclined ?)to keep pace with the PN development.
My sites aren't big - they are just small communities and a family site, although I do have one community of 380 members that averages 1200 page views a day - but an example of what happens - my family site has phpGedView which was nicely integrated until the .762 patch now the family has to log in twice to access the family tree, and don't even get me started on my large site - that's still sitting at .750 simply because the modules it uses, and the features the Community wants just don't work with anything higher than .750.
Even looking through the New Postnuke site I have found that I can't download the Security patches for .750 any longer - luckily I still have them on CD somewhere - but the problem arises that if some hole is found and I am sure one exists in .750 the only way to fix it is to upgrade and there the vicious circle begins.
I am wondering how many people have moved away from Postnuke because of these issues?
I expect I will catch some flack for this statement but I'm just wondering if Postnuke shouldn't stabilize at some point soon and allow module developers to catch up and not fear that their work will become useless two weeks down the track because Postnuke has changed again.
These are just random musings from me but honestly - what use to me is .762 or even .8 with Avantgo when I can't even find a free chat that integrates with it. It's just little things like this that vanish with each new build
that make me wonder how much longer I can continue to support my sites using Postnuke as the portal?
Surely I am not the only one in this situation that seems so frustrating?
Watch
GitHub Core
Show your support for Zikula! Sign up at Github account and watch the Core project!
GitHub Modules
- internetking created topic »password problem« 25. May
- mesteele101 responded to »ERR (3): E_USER_ERROR: Smarty error: [in pagesvar:pagesitem2en line XXX]…« 25. May
- mazdev responded to »Pages 2.5.0 and updating - Page not found« 25. May
- ehdwma created topic »Hide "Register new account" and change template to 3 col« 25. May
- mesteele101 responded to »Zikula 1.3.3 - Selecting a category in Pages not working« 25. May
- mdee created topic »How to implement returnpage ?« 25. May
- nestormateo responded to »Fillters in Clip« 24. May
Zikula Blog
- Anatomy of Open Source Projects on Mar 07
- Continuous Review on Mar 01
- Not Invented Here on Feb 24
- How to Contribute Your Code at Github on Jan 13
- 10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
- Submitting Bug Report Tickets That Get Results on Aug 17
- Cozi Tricks #1: Syntax Highlighting on Aug 07
Login
What does the future hold for Postnuke?
-
- Rank: Expert
- Registered: Feb 27, 2005
- Last visit: Apr 18, 2010
- Posts: 1577
What a collection of dilemmas.
On the one hand, there is a relentless pressure from users for enhancements to the site, new functionalities, better security, more power.
On the other hand, we also don't want to give up anything we already have.
If they leave the patches for old versions available, there is less incentive to upgrade and less pressure on the community to fix 3rd party modules.
If they remove support for old versions, it makes it hard for those of us who feel constrained to stay with 7. but I do think sometimes the answer 'Upgrade to .762' misses some of the point.
--
Peace
______________________________________
The commonest cause of problems is solutions. -
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
Once .8.0.0 comes, I belive the API will be mostly sealed, with only minor changes. Up to this point it's been a gradual move from the poor methods used by PHPNuke to the more flexible, friendly API status. I don't know what stance the Dev team takes officially, but I've always viewed PostNuke as being a very useful, but Alpha stage project. I've known since the day I started working with it that there were a lot of things coming down the pike, and that at that point, the the system was in a state of major flux. With .7.5.0+ Things are starting to settle down, processes and APIs are solidifying. That's not to say you won't have somethings break between now and 1.0 but it should get better. While it has created pain for many, over all, it's a good thing, we end up with a better, more professional system.
If your modules that break are GPL'd, then consider financial incentive to the developer to update it, things happen much faster when money is involved, and consider it a donation to the PN community, if they're not, contact the developer about upgrading.
--
Home Page | Find on Facebook | Follow on Twitter
-
- Rank: Legend
- Registered: Dec 11, 2002
- Last visit: Oct 21, 2009
- Posts: 11674
Now this is unusual, someone wanting stability, not rapid development :)
PostNuke is, and has been ever since its conception, beta (pre 1.0) software. That means that by its very nature, PostNuke is changing rapidly. PostNuke has a long way to go before it's finished, and so the change will continue to happen and will continue to be as fast as possible.
But, that doesn't preclude us from being backwards compatible, and we are. You'll find that any API compliant modules avaiable under .726 will work in the latest version, provided that they didn't implement hacks or access the core directly. This is why we provide an API, we can change the core to our heart's content while maintaining backwards compatibility.
Non API compliant modules are a different matter entirely. These are written like old PHPNuke modules, and do not use the API and in fact are simply hacked to integrate with PostNuke. These cannot be supported in new versions, since we have no idea how they were integrated. If the core changes, these modules break. Not a good way to maintain a system at all.
If developers follow our guidelines (and more and more are), then more modules will be compatible with future versions. As we move towards proper API compliance, upgrade problems should become less, and these problems will be less prevalent. Unfortunately, until .8 we have inherited the PHPNuke legacy of some poor (franky crap) code in both third party modules and the core. The process of shedding the dead weight is painful, however necessary if PostNuke is to advance and become better than its PHPNuke origins.
--
itbegins.co.uk - Zikula Consulting
birtwistle.me.uk - Personal Blog
Please read the Support Guide -
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
HammerHead
PostNuke is, and has been ever since its conception, beta (pre 1.0) software. That means that by its very nature, PostNuke is changing rapidly. PostNuke has a long way to go before it's finished, and so the change will continue to happen and will continue to be as fast as possible.
Bah semantics :P My general interpretation of "alpha" and "beta" would put PN in the "alpha" stages, beta is state of minimal change on the road to gold, alpha is where rapid changes take place, that's why I usually refer to it as an "Alpha but highly functional" product.
--
Home Page | Find on Facebook | Follow on Twitter
- Moderated by:
- Support
