PostNuke
Flexible Content Management System
News
Modules remind me of M$ weakness..
It is REALLY annoying having to go through all these folders to remove modules.
Would it be possible for the modules to be required to provide an uninstall script which simply deletes the files an tables in the DB?
The waz it is going right now reminds me of windows apps that put their stuff everywhere on your harddisk...
Thanks for consideration and/or hints.
Would it be possible for the modules to be required to provide an uninstall script which simply deletes the files an tables in the DB?
The waz it is going right now reminds me of windows apps that put their stuff everywhere on your harddisk...
Thanks for consideration and/or hints.
Post-a-review.com Postnuked!
My site is designed to be an open forum for a community of users for reviewing just about anything. Just as the name says, all you have to do is post a review through Submit News, and most likely it'll get published.
The main reviewing that I will do will be mostly in the software/hardware/books/movies areas, but any other submissions are welcome!
I'm also looking for people to join me in this project. If you're interested, email me at doug@post-a-review.com
I hope you enjoy the site!
The main reviewing that I will do will be mostly in the software/hardware/books/movies areas, but any other submissions are welcome!
I'm also looking for people to join me in this project. If you're interested, email me at doug@post-a-review.com
I hope you enjoy the site!
An idea, maybe simple?
First, when writing an article, make it use the UBB type code buttons, making inserting code easy, and easy to mark up properly.
Secondly, when writing articles, you should be able to add multiple pages (see Anandtech.com for a good way to implement it). Maybe just adding something like "Insert New Page" and another blank page to write stuff on, but linking back to other pages just to be able to edit it.
Just my simple suggestions, I wish there was a way I could help with the design of it (not the programming, I don't know PHP), but I can certainly help you to spruce up user logins, and make things easier to navigate.
Secondly, when writing articles, you should be able to add multiple pages (see Anandtech.com for a good way to implement it). Maybe just adding something like "Insert New Page" and another blank page to write stuff on, but linking back to other pages just to be able to edit it.
Just my simple suggestions, I wish there was a way I could help with the design of it (not the programming, I don't know PHP), but I can certainly help you to spruce up user logins, and make things easier to navigate.
Language and Admin Module System Changes
First the reasons for the language changes.
We all know that the vision of PostNuke is shooting for a very stable core with the plugins to be built around the core. It makes little sense that every plugin has to add to one language file. Not only does this mean that you would have to redo the language file with every upgrade to PostNuke, you would also have to modify your language files.
On top of this, there is a serious performance concern with the language structure. Currently on every page view, your server has to parse a file that is anywhere from 100k to 125k looking for defines for words. This is even when there is only 2 words to be translated on a page.
What we have done (Credit to Sam, nexia, Patrick, and Greg) is modularize the language system. Now every block has a seperate translation. Every module, whether it is an admin module or an accessible plugin has it's own language file. Your server is now only parsing a small file for the core scripts, and then the seperate translations for each plugin or block that you use.
This really allows much better performance, and also standardizes the language system for plugins. There is one drawback though. All of the current translations will need to be redone. I am sorry for this, but it was a choice that I made for performance for the overall system. The nice part will be in future versions the translations will be easier to keep up with.
Here is a layout of the new system as written by Sam:
Core lang defs are in:
/html/language/[xxx]/global.php
module lang defs are in:
/html/modules/[modname]/lang/[xxx]/global.php
or - for admin only defines:
/html/modules/[modname]/lang/[xxx]/admin.php
lang defs needed for include files can be found in:
/html/includes/language/[resource]/[xxx]/[name].php
where [resource] is currently only 'blocks'. [xxx] is the iso language name. [name] is the block name. [modname] is the modulename.
The other change is to the admin module system. The admin folder no longer exsists. We are now placing all admin modules in the module folder. The structure is the same in that folder within the modules (links, case, module) it's just located in a different place.
Why are we doing this? Well, for one it was easier to make the language system modular as well. The other reason is when you think of a plugin, you should be able to drop the entire thing into one folder and be done with it. That is where we are headed. So, the file structure is this:
For a admin only module:
modules/[ModName]/case
modules/[ModName]/links
modules/[ModName]/modules
For a plugin that also has an admin module:
modules/[ModName]/admin/case
modules/[ModName]/admin/links
modules/[ModName]/admin/modules
For most of you, these changes will be transparent. You will not see a difference in the admin, nor will you see a difference in the translations. These changes are being communicated for those of you that develope modules or help with the language files.
I believe that everyone will enjoy the differences with the structure the first time you notice a difference with performance of your site, or when you go to install or uninstall a module. Anyway, just wanted to communicate the changes in the structure with everyone that doesn't read our development list. If you want to actually see the structure changes, you can always just browse through out CVS.
We all know that the vision of PostNuke is shooting for a very stable core with the plugins to be built around the core. It makes little sense that every plugin has to add to one language file. Not only does this mean that you would have to redo the language file with every upgrade to PostNuke, you would also have to modify your language files.
On top of this, there is a serious performance concern with the language structure. Currently on every page view, your server has to parse a file that is anywhere from 100k to 125k looking for defines for words. This is even when there is only 2 words to be translated on a page.
What we have done (Credit to Sam, nexia, Patrick, and Greg) is modularize the language system. Now every block has a seperate translation. Every module, whether it is an admin module or an accessible plugin has it's own language file. Your server is now only parsing a small file for the core scripts, and then the seperate translations for each plugin or block that you use.
This really allows much better performance, and also standardizes the language system for plugins. There is one drawback though. All of the current translations will need to be redone. I am sorry for this, but it was a choice that I made for performance for the overall system. The nice part will be in future versions the translations will be easier to keep up with.
Here is a layout of the new system as written by Sam:
Core lang defs are in:
/html/language/[xxx]/global.php
module lang defs are in:
/html/modules/[modname]/lang/[xxx]/global.php
or - for admin only defines:
/html/modules/[modname]/lang/[xxx]/admin.php
lang defs needed for include files can be found in:
/html/includes/language/[resource]/[xxx]/[name].php
where [resource] is currently only 'blocks'. [xxx] is the iso language name. [name] is the block name. [modname] is the modulename.
The other change is to the admin module system. The admin folder no longer exsists. We are now placing all admin modules in the module folder. The structure is the same in that folder within the modules (links, case, module) it's just located in a different place.
Why are we doing this? Well, for one it was easier to make the language system modular as well. The other reason is when you think of a plugin, you should be able to drop the entire thing into one folder and be done with it. That is where we are headed. So, the file structure is this:
For a admin only module:
modules/[ModName]/case
modules/[ModName]/links
modules/[ModName]/modules
For a plugin that also has an admin module:
modules/[ModName]/admin/case
modules/[ModName]/admin/links
modules/[ModName]/admin/modules
For most of you, these changes will be transparent. You will not see a difference in the admin, nor will you see a difference in the translations. These changes are being communicated for those of you that develope modules or help with the language files.
I believe that everyone will enjoy the differences with the structure the first time you notice a difference with performance of your site, or when you go to install or uninstall a module. Anyway, just wanted to communicate the changes in the structure with everyone that doesn't read our development list. If you want to actually see the structure changes, you can always just browse through out CVS.
A Small Note About Blocks
Instead of using the default Main Menu where you have the "Other Options" listed, it would be better to utilize the link list block.
Now, you might be worried about the changing of names for your plugins and then having to change your main menu everytime. Worry not, my friends.
Because we have a genious on the staff (Patrick, definately not me), the idea of changing plugin folder names is built in to the link list. It is very easy to do, and doesn't require you to copy and paste the url, and here is how:
1) Create a new link list in your blocks admin and name it "Main Menu" or really whatever you want.
2) In the title of the content portion of the blocks admin, put whatever name you would like for the module. In the case of this site, I decided to name the sections, "Project Documentation".
3) In the URL portion for any plugin just place the plugin name in brackets. IE... for Project Documentation on this site I used [Sections] . If this was a NS module like the admin modules that you will see in the next release, it would be something like this [NS-Sections] .
4) In the description, just add a quick description for the link. When your mouse hovers over it, you will see that description.
Quite simple.
You also have the choice of inserting a row if you forgot and need to add another link, along with deleting an entry all together. After each new row, just save the block and move on to the next row.
I hope this helps someone that might be confused as to how to make your Main Menu ML compatible. I believe PostNuke is the only script that uses this method, so I can't vouch as to whether this ML feature can be used on any other CMS.
Now, you might be worried about the changing of names for your plugins and then having to change your main menu everytime. Worry not, my friends.
Because we have a genious on the staff (Patrick, definately not me), the idea of changing plugin folder names is built in to the link list. It is very easy to do, and doesn't require you to copy and paste the url, and here is how:
1) Create a new link list in your blocks admin and name it "Main Menu" or really whatever you want.
2) In the title of the content portion of the blocks admin, put whatever name you would like for the module. In the case of this site, I decided to name the sections, "Project Documentation".
3) In the URL portion for any plugin just place the plugin name in brackets. IE... for Project Documentation on this site I used [Sections] . If this was a NS module like the admin modules that you will see in the next release, it would be something like this [NS-Sections] .
4) In the description, just add a quick description for the link. When your mouse hovers over it, you will see that description.
Quite simple.
You also have the choice of inserting a row if you forgot and need to add another link, along with deleting an entry all together. After each new row, just save the block and move on to the next row.
I hope this helps someone that might be confused as to how to make your Main Menu ML compatible. I believe PostNuke is the only script that uses this method, so I can't vouch as to whether this ML feature can be used on any other CMS.
Page 213 / 277 (2121 - 2130 of 2763 Total)
