PostNuke
Flexible Content Management System
News
PN64 User log in problem !
if someone have an idea or can log in to my page and see what happends ,
login name : demo
password : demo
Thank youuuuuuuuuuuu
Footnote: 1
keeping article.php for bookmarks and search engines
Also, article.php makes it possible to display your full articles in a way which is more search-engine friendly, and a simple hack should make it possible to have your "read more" link set to the spider-friendly yoursite.com/article.php?sid=65, instead of yoursite.com/modules.php?op=modload&name=News&file=article&sid=65&mode=thread&order=0. This maintenance of the 0.64 article.php in the root directory appears to work for 0.7.
I discovered that google has my site's full articles listed always as http://www.webreachforpeace.org/article.php?sid=65, instead of http://www.webreachforpeace.org/article.php?sid=65&mode=thread&order=0. And /article.php?sid=65 does indeed work (on 0.7 it appears to, too, if article.php from 0.64 is in the root directory). Google was smart enough to chop off the rest. But this won't work for 0.7, because of the longer readmore links.
Google is well-known to us since it seems to be the only search engine at the moment that can trawl dynamic php sites like PN. However, it always cuts things off to the first = sign, it seems (otherwise there would be thousands of possibilities, and the googlebot has got better things to do with its time, however interesting your content may be). This is likely to change as other search engines get "smarter." But no matter how smart the search engine, they are never likely to go spider links with four = signs in them, so /article.php?sid=65 just makes your whole articles a whole lot more spiderable.
All the stuff after this in 0.64 (mode and order) are so users who configure "comments configuration" by changing the user options can have their pick as to how comments are displayed. But have YOU ever really done this? Imho this option is a bit of a legacy from phpnuke that should be eliminated from the user options--users are presented with these options whenever they display comments, anyways. I hacked this option out of user.php a while ago, and am considering hacking the News module (with the old article.php it's comments.php) so it only displays the "flat" read, which seems to be the most popular way of posting in forums, and seems to make reading/ordering discussion easier (as well as making things appear cleaner).
I'm still in the process of porting to 0.7 and haven't made any of these hacks yet. However, I'd be interested in hearing what the PN community thinks of these hacks before I make them (or maybe somebody out there is kind enough to do them for me)--especially, e.g., if there would be any security issues here. I haven't tested 0.64's article.php with 0.7 very much yet. Here is one big problem with it, though: article.php does not have the $preformat, $info or $links functions which are the new standard for 0.7 themes. If you want to use article.php, you will have to use $title instead of $preformat[catandtitle], to name one example...in other words, everything in function themearticle and function FormatStory of your theme.php will need to be set according the "backwards compatible" strings. Also, remember to upload the 0.64 comments.php as well.
The PN dev team is working on making PN with more search-friendly strings. The solution above could an option for some who have long articles needing to be spidered before this happens, although it's quite awkward. I'd like to hear more about what the PN community thinks about this.
I discovered that google has my site's full articles listed always as http://www.webreachforpeace.org/article.php?sid=65, instead of http://www.webreachforpeace.org/article.php?sid=65&mode=thread&order=0. And /article.php?sid=65 does indeed work (on 0.7 it appears to, too, if article.php from 0.64 is in the root directory). Google was smart enough to chop off the rest. But this won't work for 0.7, because of the longer readmore links.
Google is well-known to us since it seems to be the only search engine at the moment that can trawl dynamic php sites like PN. However, it always cuts things off to the first = sign, it seems (otherwise there would be thousands of possibilities, and the googlebot has got better things to do with its time, however interesting your content may be). This is likely to change as other search engines get "smarter." But no matter how smart the search engine, they are never likely to go spider links with four = signs in them, so /article.php?sid=65 just makes your whole articles a whole lot more spiderable.
All the stuff after this in 0.64 (mode and order) are so users who configure "comments configuration" by changing the user options can have their pick as to how comments are displayed. But have YOU ever really done this? Imho this option is a bit of a legacy from phpnuke that should be eliminated from the user options--users are presented with these options whenever they display comments, anyways. I hacked this option out of user.php a while ago, and am considering hacking the News module (with the old article.php it's comments.php) so it only displays the "flat" read, which seems to be the most popular way of posting in forums, and seems to make reading/ordering discussion easier (as well as making things appear cleaner).
I'm still in the process of porting to 0.7 and haven't made any of these hacks yet. However, I'd be interested in hearing what the PN community thinks of these hacks before I make them (or maybe somebody out there is kind enough to do them for me)--especially, e.g., if there would be any security issues here. I haven't tested 0.64's article.php with 0.7 very much yet. Here is one big problem with it, though: article.php does not have the $preformat, $info or $links functions which are the new standard for 0.7 themes. If you want to use article.php, you will have to use $title instead of $preformat[catandtitle], to name one example...in other words, everything in function themearticle and function FormatStory of your theme.php will need to be set according the "backwards compatible" strings. Also, remember to upload the 0.64 comments.php as well.
The PN dev team is working on making PN with more search-friendly strings. The solution above could an option for some who have long articles needing to be spidered before this happens, although it's quite awkward. I'd like to hear more about what the PN community thinks about this.
Content Management Ideas
As you can see from the GIF provided, an ideal setup for the content management database schema would include 3 tables. Read over the setup here, and if you have any questions, please let me know.
This is of course the most obvious. Content at the base level is the same across the board. Whether the content is news, articles, section content, or whatever you want to call it (heck, even comments!), they are all the same.
Table Schema and Explanation
Table: content
Field: id
The id field is simply the unique id (or a sequence) of the content. This is common enough.
Field: type
Somewhat abstract, however, type is important in human terms. What 'kind' of content is this? Content can a front page news article, section content, heck, even comments or forum posts. This allows for a special abstraction and making this system a core system would allow other applications using PostNuke a common content setup to use. They could define their own 'type' of document, and simply use that table. This would make searching the content of the site really easy as well.
All news items could have the 'news' declaration put on them. Namespaces would have to be enforced, so you could enforce a 'modulename_type' of system, and use 'core_type' for anything the core system uses.
Field: status
Status is important in a CMS. Content Management is the key, and just because content is in the system doesn't mean anyone should be able to look at it. It is important to remember what a CMS is. Giving status several possible values, like "Published", "Under Review", "Editing Phase 1", "Editing Phase 2", "Rough Draft" and finally, "Queued for Deletion" would allow PostNuke to take on a better CMS status. Integrating this with your proposed new user system could also be a boon, allowing only certain levels of users to "Publish" content finally. You can also set certain types of content, like comments, to be set to "Published" automatically, or allow admins to create "content rules".
Field: promotion
Another abstract term, yet something used to help describe how the system should handle the data. Most obvious use is the Drupal style of promoting the content, whatever it is, to the front of the page. This means you can quickly and easily add new content, or a comment, as a front page news item and 'promote' it. Of course, setting up something so that all "news" items are set as being promoted to the front page would be a good case.
Field: title
Self explanatory, the title of the content.
Field: abstract
Self explanatory, the abstract of the content.
Field: content
Finally, the content itself.
Table: content_author
Basically a one-to-many setup here. Content can have more than one author, and setting up an author's table containing important authors info would be important. This can link to the users table if need be, but not all author's may be users.
Field: content_id_fk
Foreign key to the content id.
Field: author_id_fk
Foreign key to the author id.
Table: content_category
Again, like the content_author table, content may be contained under more than one category. An article on PHP and MySQL may fall under 2 categories, PHP and MySQL.
Field: content_id_fk
Foreign key to the content id.
Field: category_id_fk
Foreign key to the category id.
What we have here is a working content model. As you can see in the diagram, we have defined content in a relatively simple matter.
Overall, it is important that content be managed as a core system. However, defining the content should be left up to the modules.
This is of course the most obvious. Content at the base level is the same across the board. Whether the content is news, articles, section content, or whatever you want to call it (heck, even comments!), they are all the same.
Table Schema and Explanation
Table: content
Field: id
The id field is simply the unique id (or a sequence) of the content. This is common enough.
Field: type
Somewhat abstract, however, type is important in human terms. What 'kind' of content is this? Content can a front page news article, section content, heck, even comments or forum posts. This allows for a special abstraction and making this system a core system would allow other applications using PostNuke a common content setup to use. They could define their own 'type' of document, and simply use that table. This would make searching the content of the site really easy as well.
All news items could have the 'news' declaration put on them. Namespaces would have to be enforced, so you could enforce a 'modulename_type' of system, and use 'core_type' for anything the core system uses.
Field: status
Status is important in a CMS. Content Management is the key, and just because content is in the system doesn't mean anyone should be able to look at it. It is important to remember what a CMS is. Giving status several possible values, like "Published", "Under Review", "Editing Phase 1", "Editing Phase 2", "Rough Draft" and finally, "Queued for Deletion" would allow PostNuke to take on a better CMS status. Integrating this with your proposed new user system could also be a boon, allowing only certain levels of users to "Publish" content finally. You can also set certain types of content, like comments, to be set to "Published" automatically, or allow admins to create "content rules".
Field: promotion
Another abstract term, yet something used to help describe how the system should handle the data. Most obvious use is the Drupal style of promoting the content, whatever it is, to the front of the page. This means you can quickly and easily add new content, or a comment, as a front page news item and 'promote' it. Of course, setting up something so that all "news" items are set as being promoted to the front page would be a good case.
Field: title
Self explanatory, the title of the content.
Field: abstract
Self explanatory, the abstract of the content.
Field: content
Finally, the content itself.
Table: content_author
Basically a one-to-many setup here. Content can have more than one author, and setting up an author's table containing important authors info would be important. This can link to the users table if need be, but not all author's may be users.
Field: content_id_fk
Foreign key to the content id.
Field: author_id_fk
Foreign key to the author id.
Table: content_category
Again, like the content_author table, content may be contained under more than one category. An article on PHP and MySQL may fall under 2 categories, PHP and MySQL.
Field: content_id_fk
Foreign key to the content id.
Field: category_id_fk
Foreign key to the category id.
What we have here is a working content model. As you can see in the diagram, we have defined content in a relatively simple matter.
Overall, it is important that content be managed as a core system. However, defining the content should be left up to the modules.
Html Tables
Footnote: 1
Page 146 / 277 (1451 - 1460 of 2763 Total)
