PDA

View Full Version : simple CMS


Tjobbe
January 20th, 2005, 13:30
I'm trying to get started with PHP again, and I want to be able to create a really simple CMS but I'm having difficulty figuring it all out.

I will have a simple index page, that I will post news to, the index.php page will simple had a database connect and display everything from that table here script.

In the table will be the html of the page.

I will have another page, edit.php that connects to the db, displays the table results in a textarea and that i cna edit and click submit to write the data to the db.

What I'm struggling with at the moment is creating the database.

I would like the databse to contain all my html, from <html> to </html> and evrything in betwee, that way i can easily edit the page on the edit.php file.

How would I create the table in phpmyadmin to be able to store html?

I'm new to php but i was trying to create this in phpmyadmin and i was thrown well of course, if someone understand what im trying to do, please put me out of my misery and point me in the right direction!

Thanks!

Anoop
January 20th, 2005, 14:47
HI,
You can create a table having two fields, an id and content. Id will be a unique id(ie primary key autoincrement) and content, a text type. You may also need the htmlspecialchars() function to display back the html.
For example , in edit page you can write something like
Query the content from the table and store it in $content
<textarea> <? echo htmlspecialchars($content); ?></textarea>
which will display the html contents with in the text area.

-Anoop

Tjobbe
January 20th, 2005, 14:49
Excellent, thanks Anoop. I'll get straight to it!

Tjobbe
January 20th, 2005, 17:38
something im doing wrong, i just cant seem to do it.

heres a screen shot of what im doing:

http://www.farstyle.com/screen.gif

what am i doing wrong and what does this mean?:

Error

SQL-query :

CREATE TABLE `content` (
`id` VARCHAR( 10 ) NOT NULL AUTO_INCREMENT ,
`content` TEXT( 99999 ) NOT NULL ,
PRIMARY KEY ( `id` )
)

MySQL said:
#1063 - Incorrect column specifier for column 'id'

ethicaldesign
January 20th, 2005, 18:20
ID can't be a varchar and also auto_increment. Auto increment fields need to be numbers. If you change that to an integer that should work (I would keep the auto_increment though so you've got some unique page IDs to reference when you write your edit script).

You might also want to consider adding an additional field to hold the page name for navigation links for the creation of new pages (assuming you're going to generate the navigation aswell)

Perhaps an additional field for the page title (that goes between the <title> tags) so they can be entered and edited in the admin.

Maybe also some varchar fields for meta tag keywords and descriptions so you can specify these seperately for each page.

On any CMS functions that I've done, rather than contain all of the page (including the <html> tags) in one field I would tend to just store the basic page code in that field then put everything else seperate in the database and deliver it up using php with some code that'll combine the fields into a html code. So your header area of the code for example would be generated from a script that pulls the information required (keywords, descriptions etc) from the database, and outputs it to html along with any style sheet inclusions etc. that you need.

Doing it that way means that if you ever want to make an edit to any of the surrounding code you only need to do it once in the php file that generates it for all of the pages and it'll be reflected across the whole of the site.

I know metatags and descriptions aren't as important as they used to be but it's handy to have them in for some of the smaller engines, and if you've got them in the database if you ever need to add a site search feature you can use the keywords for that aswell and it'll work a bit faster than searching full site text.

Tjobbe
January 21st, 2005, 18:26
still having problem, I have created a database and clalled it html, i then made a table called body with two fields, id and content.

ID is type: 'INT'
length/values:'1'
Null:'Not Null'
Extra: 'auto_increment'
primary: 'ticked'

then for the content field, where I'm hoping to actually store the html which goes between the <body> and </body tags> I have set the following:

Field: 'content'
type: 'text'
length/values '99999'
null: 'not null'


and that keeps giving me an error like this:

Error

SQL-query :

CREATE TABLE `body` (
`id` INT( 1 ) NOT NULL AUTO_INCREMENT ,
`content` TEXT( 99999 ) NOT NULL ,
PRIMARY KEY ( `id` )
)

MySQL said:
#1064 - You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near '(99999) NOT NULL, PRIMARY KEY (`id`))' at line 1

if I change the 'type' to blob or aything else i get errors. how do i create the table to store html data, thta i can call up from a php file as Anoop suggested?

sonicgroup
January 21st, 2005, 19:49
Text fields do not have a size, simply specify it as TEXT or BLOB (or the TINY or LARGE variants). Also, I'd specify the largest length for your ID (11 in the case of INT). Specifying a length of 1 will only allow you to have 9 records (since auto-increment counts from 1).

Tjobbe
January 21st, 2005, 19:53
Text fields do not have a size, simply specify it as TEXT or BLOB (or the TINY or LARGE variants). Also, I'd specify the largest length for your ID (11 in the case of INT). Specifying a length of 1 will only allow you to have 9 records (since auto-increment counts from 1).

thanks, I only need one record for now, I'l only be doing this on one page, for the time being.

Tjobbe
January 21st, 2005, 19:55
that worked a treat, thanks very much indeedy.

sonicgroup
January 21st, 2005, 19:57
No problem. ;)

ethicaldesign
January 21st, 2005, 23:16
Also, I'd specify the largest length for your ID (11 in the case of INT). Specifying a length of 1 will only allow you to have 9 records (since auto-increment counts from 1).

I would agree with using a larger than one byte INT (tinyint), because you never know how much a site is going to grow, but I think the way to do that with mysql/phpmyadmin is to specify bigint,smallint,mediumint etc.

They're measured in bytes, with the smallest element being tinyint which uses one byte and would allow for numbering up to 255 (assuming it's unsigned).

INT I think allocates 4 bytes, so should be OK.

I think when you specify numbers in brackets like that it doesn't actually change the number of bytes allocated but is to do with padding (the reason why you might use 11 would be to ensure that there's enough padding to account for the maximum number of places that might be used for an INT type which is 4 bytes long - though 10 would probably do it if it's unsigned I think).

At least that's the way I'm reading it.

If you specify unsigned, then it doesn't allow for negative numbers and will allow a higher number (of positives) to be stored in each byte.

There's an explanation of this here:

http://dev.mysql.com/doc/mysql/en/Numeric_types.html

sonicgroup
January 22nd, 2005, 01:28
11 is the number of places reserved (i.e. padding). 11 is the default (and largest) that specifying an INT type with no length would yield.

ethicaldesign
January 22nd, 2005, 10:56
11 is the number of places reserved (i.e. padding). 11 is the default (and largest) that specifying an INT type with no length would yield.

That's what I said. I was just pointing it out to clarify because it could be a bit misleading to someone who starts out, because the syntax INT(1) could easily be interpreted as an integer with one byte allocated (that's the way I would have read it if it was something new to me, particularly as the same format applies to other fields like chars etc).

Adding unsigned is probably a good idea aswell though, because if you're just using these as field identifiers, you most likely don't need to use negative numbers (particularly bearing in mind it's an auto-increment field). That'll give you more places to play with (a smallint would probably more than suffice for what you need, though the space saving in the db for something on this scale makes it less of an issue). Something to bear in mind if you ever need to create a db that's going to store a lot of records though.