Database Driven Website

[chintoo]

Dear All,

I want to know how website will be made/languages used with following requirements :

I am roughly 1000 Page Static Website. Each page contains 1 main heading, sub heading, content and 2-3 photos per page

along with the main template of the website. I had made it by making 1000 static pages and its hectic to maintain. I want a

website which should be like this :

1. I want to place all 1000 articles in txt OR doc OR rtf ... OR any format... in 1 folder.
2. 2000-3000 Photos in another folder. (2-3 Photos per page)
3. Now when anyone clicks any of the thousand links in main template, a PHP code or any server side language code should

pick up an article from txt file and images from 'photos folder' and make a page which includes article ,images placed at

proper place.

Now how can i do it ? What languages will be involved ? How it will be made ? Kindly help me out !

[weegillis]

To #1. .txt or .html would be the format for the files. .DOC, .RTF or others will be bloated, and cannot be edited on the fly with Notepad or other plain text editor.

The pages are already tagged, so you could just copy the 'content div' and save it to the new destination with the name or id you want to use (as in, .html or .htm, or even .php). Keep the tags, and even the class names and ids. The style hooks will already be in your CSS, making restyling a simple task you can tweak as you go. If the site has DOM scripts, chances are some of those ids (or possibly classes) are sought out as well. Another reason to keep the tags and attributes.

You'll need to do this a thousand times, so it will take some work. It is possible to automate some of the process with JavaScript. Write a function that hooks the content div, copies it, then overwrites the existing page, leaving only the content div. Then save page as and Back to remote page and do it again with your next page. The saved pages will likely still have doctype and <html/html> tags which would need to be removed in a text editor (or Dreamweaver, in a couple passes). After that, you've got your content modules.

There is no opening or editing of server files, only creation of new ones, which are stored locally. For ease, you could even keep the URI, as they will never conflict with anything in their own folder.

===

Not that it's a problem having 1000 pages in one folder, but 1000 links in one index page is a tall order, and totally impractical (and not very usable). One would presume there is some order to the content now, such as categories or grouping of some nature. Might these become the root index of their own folder, with only those included pages alongside? 100 links in a main index is not so bad, 50 is better. Having around 5 for simple site-wide navigation in every page would allow quick traversal across large groups. Each of the 5 (or so) would be indexes of still more indexes.

The index.php at each level would share the template intended for its level, and would fork to the engine needed to generate a page at that level. The engine, by the way would be written in PHP on the server, and JavaScript on the client side (for DOM manipulation such as adding e-mail addresses, setting event handlers, etc.).

The manner you describe does not appear to include a database, so none is discussed in the above method. For my own purposes, I would just write the PHP and store the files, but there may be other opinions on this method, which favor the use of a database. You would still need to capture all the content, so the above copying/saving method still applies, but instead of eventually uploading them to a remote folder, you add them to the database. In this case, you may as well go out and buy Thesis, and forget all the other stuff.

But, if you don't want a blog, or a CMS, or to maintain a database, PHP can be made to manage your 1000 pages and 2000 photos very nicely, and the server will be the database (the relationships will all be hardcoded in your templates and index tables).

The Little Schools link in my sig is undergoing a rebuild in the manner I've described. The template is designed to handle two photos merged into tagged content that is retrieved from its respective content folder. The navigation is sensitive to the request URI permitting Previous/Next links to be dynamically created based upon adjacent rows in the folder table.

This may well be very old school, and may also have issues. Being a hobbyist, I cannot speak with a professional objective view, only what works for me in my own craft. I needed something that worked without a database, and now I have it in a handful of different forms. All with basic and simple PHP (and some logic).

[chintoo]

Thank you so much for reply. Yes i was looking for something like a website in your signature. Basically , i have website of birds with thousand pages which is hectic to maintain. Just like your school website in signature i want to categorize birds in this way and provide link for each bird.

Now first of all ,

1. Is there a way that i make a template and leave blank the content area and photos area. When user click on any link eg XYZ then any script/code ( javascript/PHP........) grabs the content from txt file and photos from photos folder and combine in a new page mywebsite.com/xyz.html or mywebsite.com/xyz.php. In this way i will not need to make thousand pages manually.
2. If this is possible then will google add such pages in search engine ?

To #1. .txt or .html would be the format for the files. .DOC, .RTF or others will be bloated, and cannot be edited on the fly with Notepad or other plain text editor.

The pages are already tagged, so you could just copy the 'content div' and save it to the new destination with the name or id you want to use (as in, .html or .htm, or even .php). Keep the tags, and even the class names and ids. The style hooks will already be in your CSS, making restyling a simple task you can tweak as you go. If the site has DOM scripts, chances are some of those ids (or possibly classes) are sought out as well. Another reason to keep the tags and attributes.

You'll need to do this a thousand times, so it will take some work. It is possible to automate some of the process with JavaScript. Write a function that hooks the content div, copies it, then overwrites the existing page, leaving only the content div. Then save page as and Back to remote page and do it again with your next page. The saved pages will likely still have doctype and <html/html> tags which would need to be removed in a text editor (or Dreamweaver, in a couple passes). After that, you've got your content modules.

There is no opening or editing of server files, only creation of new ones, which are stored locally. For ease, you could even keep the URI, as they will never conflict with anything in their own folder.

===

Not that it's a problem having 1000 pages in one folder, but 1000 links in one index page is a tall order, and totally impractical (and not very usable). One would presume there is some order to the content now, such as categories or grouping of some nature. Might these become the root index of their own folder, with only those included pages alongside? 100 links in a main index is not so bad, 50 is better. Having around 5 for simple site-wide navigation in every page would allow quick traversal across large groups. Each of the 5 (or so) would be indexes of still more indexes.

The index.php at each level would share the template intended for its level, and would fork to the engine needed to generate a page at that level. The engine, by the way would be written in PHP on the server, and JavaScript on the client side (for DOM manipulation such as adding e-mail addresses, setting event handlers, etc.).

The manner you describe does not appear to include a database, so none is discussed in the above method. For my own purposes, I would just write the PHP and store the files, but there may be other opinions on this method, which favor the use of a database. You would still need to capture all the content, so the above copying/saving method still applies, but instead of eventually uploading them to a remote folder, you add them to the database. In this case, you may as well go out and buy Thesis, and forget all the other stuff.

But, if you don't want a blog, or a CMS, or to maintain a database, PHP can be made to manage your 1000 pages and 2000 photos very nicely, and the server will be the database (the relationships will all be hardcoded in your templates and index tables).

The Little Schools link in my sig is undergoing a rebuild in the manner I've described. The template is designed to handle two photos merged into tagged content that is retrieved from its respective content folder. The navigation is sensitive to the request URI permitting Previous/Next links to be dynamically created based upon adjacent rows in the folder table.

This may well be very old school, and may also have issues. Being a hobbyist, I cannot speak with a professional objective view, only what works for me in my own craft. I needed something that worked without a database, and now I have it in a handful of different forms. All with basic and simple PHP (and some logic).

[weegillis]

Google can/will add what it adds as it sees important. This is why the intermediary indexes are important. They will steer the robots to pages deep within your site, and get them indexed, maybe. What gets indexed is up to Google, or Bing, or Yahoo!. If you want your deep pages indexed, then index on them on your site, and let the search follow your index pattern.

From what you just said, I'm now wondering if the content already exists, or not. Is this still a concept, or are you reworking an old site?

If not, then you have a slightly different task ahead. You need to get some static pages up and running. Then you can determine what the variables are, and start to set up your index tables. Once you populate the tables, you replace variable content with function calls to echo statements that are dynamically loaded with page data.

Do you have an existing layout, already? If not, that will need to get sorted away, too, before you can template it. Where are we right now?

[chintoo]

Yes i already have website and i want to develop more but it haunts me thinking of making 1000 pages. I have emailed/Private messaged you one of such website which i had made.

I have template,Now whats the first step.Any ideas ?

Google can/will add what it adds as it sees important. This is why the intermediary indexes are important. They will steer the robots to pages deep within your site, and get them indexed, maybe. What gets indexed is up to Google, or Bing, or Yahoo!. If you want your deep pages indexed, then index on them on your site, and let the search follow your index pattern.

From what you just said, I'm now wondering if the content already exists, or not. Is this still a concept, or are you reworking an old site?

If not, then you have a slightly different task ahead. You need to get some static pages up and running. Then you can determine what the variables are, and start to set up your index tables. Once you populate the tables, you replace variable content with function calls to echo statements that are dynamically loaded with page data.

Do you have an existing layout, already? If not, that will need to get sorted away, too, before you can template it. Where are we right now?

[weegillis]

Are you working in Dreamweaver? The template in DW will be similar to, but not the same as the one I describe. DW's template works by allowing editable content within the template, mine does not. My template is rarely or never edited. It just lives on the server and is used as a boilerplate to insert data related to the requested URI. All of the insertion points have PHP function calls.

This is why I suggest getting a few static pages in place (a couple for each type of page) then course through them and identify the unique bits of data (including heading and navigation). These are the bits that will go into your data table (or includes modules).

I looked at the source code of the site you sent me, and have to say, it was a lot of work to put that together. But there are issues that will come back and bite you squarely on the tookus: namely, uppercase first letters and underscore separators. One of the things I learned very early on was to stick to lowercase. SE's have told us not to use underscores as word separators. Use dashes instead, else the term is seen as one long word that makes no sense.

It's a bit late to change that now, but for your next site, drop the practice altogether. Go with lowercase on everything relating to URL's, fragment id's and class names. In the OOP world, uppercase first letter is used to denote an object class, if I'm not mistaken. Let them (the OOP programmers) have their convention, and not try to create one of your own around uppercase.

href="/Electric_Circuits/Electric_Circuit_Theory_1.htm"

In your next project would become:

href="/electric-circuits/electric-circuit-theory-1.htm"

I also noted there is no quoted source for the information on the site (and there are several errors and inconsistencies in just the pages I looked at, but that is not the discussion here).

One thing is certain about templates... if they are not valid, none of your pages will be, either. Once you create a static page, check it in the W3C validator and correct any detected errors. I would recommend going with the HTML5 doctype to help clear out some of the old HTML (XHTML) clutter and simplify the markup. HTML5 is Strict, but allows either HTML 4 or XHTML markup. This means <br> and <br /> are both valid, as are all the other self-closing elements like <img>, <input>, <hr>, and so on. HTML5 permits dropping of TYPE attributes on <script>, <link rel="stylesheet"> and <style>. It is also the markup language being used by FB, so their content will ring up less validation issues. (There will always be issues with FB, but that's no matter. Only they parse these parts of the page.) Just make your markup valid, before you create the template from it.