View Full Version : PHP - MySQL Portal software

10-26-2003, 05:42 PM
I have installed and played around with postnuke and php-nuke systems. I like them: usability, ease of content management, and the ability to update from an email cafe.

I have a couple of concerns:

Security - are they easily hacked?

Search - will search engines recognize my content?

Overload - They seem to have a good deal of options that I will never use.

I need a BBS system, some type of 'blog', and a picture gallery. I would like them to be tied together with a search function and user registration. My knowledge of PHP and MySQL is that of a beginner. I am an expert at HTML, javascript, flash and quicktime. I wonder if it's better to stick with what I know or plunge into a turn-key solution [I hate that expression]

Any suggestions?

10-26-2003, 07:50 PM
php-nuke is not very se friendly.

Most popular CMS's aren't for that matter.

I develop my CMS's from scratch, much more control that way.

Now, for the BBS and the Gallery...

photopostphp (photopost.com) can integrate with popular forums, including vBulletin. So if you're up for spending $300 you can get a nice forum/gallery package in the form of photopost and vbulletin.

10-27-2003, 12:24 PM
I just spent the day flipping through the o'reilly google hacks book. The way they explain page rank a plain HTML site with 400 static pages would perform better than a site that is dynamic, being created on the fly from a database.

Did I understand that correctly? How does google spider through a database?

10-27-2003, 01:23 PM
That Google Hacks book is useless from an SEO standpoint -- most if it is plain wrong.

The information on the Google API is useful, but it is not an SEO book.

Google cares nothing for files or databases, only for unique URLs. As long as the URL is unique Google doesn't care if it was generated by a database or a static file.

There are some issues involved with dynamic sites, but they have nothing to do with PageRank.

Basically you should avoid variables named "id" in your query strings, also session IDs are a bad idea. Otherwise you're fine, but to get the best performance you should use SE friendly URLs.