Flexible Content Management System


Lot of things to say.

Contributed by Anonymous on Aug 25, 2001 - 12:19 PM

1. I will begin by a multilingual issue. As other I think, I have developed a site for discovering later the existence of php nuke and then post nuke. Even if this system offer quite all the tools necessary, they are not necessarily the best for all or you would not forget all the work you have already done. For my part, I run “links2” from Gossamer which is a free and powerful links manager. I have work hard to make it as I wanted and to feed it. You can see it in action on my site at links.

Ok, that just an example about tools that we want keep alive in our own site. But of course we try to integrate our tools as much as we can. So, as my site is multilingual, I would like to implement the multilingual feature from Postnuke. The problem is that I don’t know very well how this feature works. I mean I know how to use tags and how to implement vocabulary files but unfortunately I don’t know how to detect the language currently in service. I suppose we need to play with cookies but how to decode it, especially when my files are not in the root of Postnuke. But I think is not a problem cause a cookie can be read from an other folder ?? well that my first question. Is someone have some tutorials about how Postnuke works or is it to early to ask cause is in beta ? But I think it’s the same problem to develop modules. How to adapt which are existing if we don’t know what we must change ?

I think you will find that quite a few perl scripts like Gossamer Threads, would require quite a lot of work to work with PostNuke. I would perfer to look at functionality that is similar, than trying to port something that would take much longer

2. Also, the second issue is about modules and addons. As I like to have Gadgets ;) like child, I like to implement new tools on my site for the happiness of my visitors. I have found lots of interesting thinks from time to time. As everybody, we know how is frustrating to see feature working in other site but not on our, cause these modules have been primarily developed for PHPnuke. Everyone have notice that we are poor (Postnuke users) about working modules ;-( It’s cool to have a stable and well written “OS” but without applications to use with, who cares) That was the case of Linux against Windows. So I think it’s important to create a “real and clean” approach to increase the number of “Certified Postnuke modules”. As someone said it’s cool to offer this kind of guaranty which mean that a module have been correctly tested and written for Postnuke. I don’t want to blame anyone ;) but to be honest the “mutant_plugins pakage” was not a success at all. Only 2 modules had worked. And the forum…. Héhé I will come back later to speak about that. Well, concerning this issue, what I suggest is to create a board where everyone who found a module, will put information about it in a same place. So everyone will know what kind of module we can find among the php community. I say PHP community because sometime we found great tools that could me easily (or not so easily) transform in a module. We don’t have to reinvent the wheel all the time. I have already spoke with one module developer and he is ready to port his php module to Postnuke. I think that most of time, developer will be nice enough to make it available for Postnuke as long as it still compatible with PHP Nuke of course. Ok, I continue with my idea… The board will be viewable by everyone, and will offer this options:

a. Everyone put his ideas about a module he found or he would like to found.

i. This module exist and works for Postnuke (need to be certified),

ii. This module exist and but I’m not sure if it’s work for postnuke,

iii. This module was made for php nuke and don’t work for postnuke,

iv. This module doesn’t exist but can be built as modules,

v. I found a nice soft and would like that someone port as a module,

vi. I have an idea of a module,…

b. We offer the possibility to everyone to vote for the modules they want first. So we can develop modules, in priority, those which are the most needed. But of course everyone is free to develop which he wants in priority.

c. Then the next board will show:

i. the name of the module,

ii. the definition of it,

iii. the functionalities,

iv. which developers take care of this module,

v. the new functionalities that people would like to see implemented,

vi. the stages of the module development,

vii. ….

This, in order to know who do something to avoid people doing the same thing twice. We know how is frustrating to find 2 great modules which do the same things but both have one functionality that the other one don’t have. So, if we want both of this feature in our site we must choice one or install both modules ;-( . The better example to give is the module memberlist. Héhé I can’t tell you how much people have the both version in their site (like me, ok).

Well, this is how I see the things to perform and to go, all, in the same direction ;-)

Your ideas are valid, but right now, we are concentrating more on the core of the script to make the use of plugins even easier. If the core of the script is small, versital, and fast, then the plugins become even more viable.

This might however help those of you that are working on plugins to meet your site specific needs. Most plugins that I have found spring from necessity, rather than luxery.

Oh yes, 3rd issue. Concerning existing modules. As I saw in the forum, when we have problem installing a module, users explain their problem with it, and “niceguyeddy” (really nice guy) try to check where is the problem to solved it. But don’t blame it, if after one week the discussion fall in the dungeon and the problem still there. That’s normal cause he have to much thinks to do. As example here I will speak about Submit DHTML module ;) We still want it. Or IM-Buddy which still not a module at all. So, to solve this problem we need again a board where we will find :

1. the name of the module,

2. the problems encounter,

3. the causes and the error message,

4. the stages to solve problems (with colors green for problem solved, yellow for problem take in consideration by a developer, red for a problem not yet take into consideration). When I say problem solved, I want to say really solved and certified solved by the “Postnuke team” cause I see often someone says : “I’ve solved the problem but he haven’t test it widely before to say that, and the problem still be present.

Ok don’t know if I lost all of my readers but I continue héhé ;-)

Of course all I said before is valid for Postnuke development. When we notice a problem or when we have some idea about improving Postnuke where do we put our requests ? on the forum or you submit an article of course, but after one week who remember what you said and what the postnuke team answer ? You need to do a wide search inside forum or articles to see if the topics was treated. We need here again to see what’s going on. To follow and above all to not forgot what has been asked:

1. Where are you in the development stage,

2. Is my idea took into consideration,

3. Is this idea will be implemented in the next release,

4. Is this idea important for all ? Here again users could vote for the features they think are the most important.

5. some color again to see :

a. green, the feature is now implemented for the next released,

b. yellow, the feature is in course of development,

c. red, the feature is not yet take in consideration,

An example again ? Yes of course ;) I have notice that in postnuke 0.61 we can’t modified the type of the block we create, so I have ask if we could next time change the type of block (simple include file, html, links block,….) as we can change block language or position at anytime. The answer was yes it will be done for the next released but it’s still not ;) Here again I don’t blame someone ;) Just try to explain what we can do, to improve things ;) I’m a strategic consultant, it’s why I like to improve the way to manage things and to make the life better. Perhaps it will be done for the next release, perhaps they forgot, and perhaps someone will asked the same question again and again cause he doesn’t know if someone else have asked the same question 2 or 3 weeks before.

Concerning block I take the advantage to tell you that I encounter problems.

If I use :

 simple file include: it doesn’t interpret the php code of the file and show it’s content (code lines). In the file window I see this : “$row[url]“ how do I use it ? if I put an url inside [] no block appeared. If I put url inside the window and erase the code showed before, I can see the content of an html file correctly but if I come back to change block configuration the link have disappeared and I must retype the file root.

 Php script : I got error, can’t interpret ….error line 1….

So I use html block as before with a hack in my theme which interpret the path root of a file put inside the block. So I got my php file interpret correctly inside a block. But, because is there a but ;-) if I switch to an other language, the content still be in English for all language) .

For any bug what so ever, if it doesn't end up on SourceForge, then there is always the possibility that it will be lost on the forums. There are links to the bug reporting all over this site. It just needs to be used, so we can track and assign the problems:)

Ok it’s time to stop my annoying letter. Now I still alone to read myself boooooooo.

I will finish by the forum issue as I told you before. I just want to inform you that I found a really great and also free forum which will soon work with sql database. But use cgi to run. After lots of comparison it the direct challenger of “Vbulletin” the reference. Take a look at www.ikonboard They’re official and multilingual version will be available in the next two weeks. Test it, it’s a very very powerful forum .

Ok I have finish for now and I will come back soon to know what everyone thinks.

Thanks again to everyone for their job.