Jump to content

Recommended Posts

I am thinking of converting a website I had previously made for my brother from HTML to PHP. The website's structure isn't too complicated so I'm not worried about links and so on. However, being new to PHP, is using $_GET content a great way to access page content (e.g. from a database)? Say, page 1 has some content in the database and page 2 has some other content, is using .../content.php?page=1 and .../content.php?page=2 safe? Secure? Coming from HTML where every page was in a separate file, it just seems somewhat dodgy.

 

Which brings us to, what would be a good way to incorporate tables, images and so on into a Content Management System? It seems fairly simple to provide a page name, visibility button, a content box for text and such, but what would be an easy way to add images/tables (for someone who does not want to use HTML/CSS)? Should I consider making a simple word processor style editor for the page (wysiwyg)? It still seems fairly complex but I suppose doable, I suppose it will mostly use client-side code for the editing and PHP to save changes. I'm not too worried about the coding that will have to be done but more, what would be a good way of representing an easy to use user-interface? Being new to PHP, I'm open to new ideas!

 

Cheers,

Amp

I'm not too sure about your second paragraph but, for your first, if you are using anything located in the url in a query, make sure you use mysql_real_escape_string($_GET['whatever']); (or mysqli/PDO) Then it should be safe.

Edited by SocialCloud

If you're using a database, then passing the ID of the page through the URL is perfectly fine -- assuming you sanitise the ID and validate the 'visibility' you mentioned, before displaying the page.

 

CMSs like Wordpress allow you to define a unique slug for each page and blog post, which means you don't have to expose the ID and makes the URLs a little cleaner and more descriptive. For example an "About Us" page, you can define the slug as "about-us", and requests to "/about-us" would be rewritten to "/page.php?slug=aboout-us" (or something along those lines) using the Apache rewrite module. The draw back here though is you need to store an additional piece of data for each page.

 

Alternatively, like on these forums, you can combine the ID with the title of the page (lower-cased and with certain characters removed) in a set structure, so that you can parse out the ID and retain the descriptive URLs without having to store a separate slug. Again, you would rewrite the URL internally using the Apache rewrite module.

 

If you're not bothered about having descriptive URLs, but also don't want query strings in them all, you could simply rewrite the request from something like "/page/123" to "/page.php?id=123".

 

As for the editor, there's already some free and open-source WYSIWYG editors out there you can use. Most allow you to import your own styles so that what the user sees as they're editing is largely in-line with what the finished product will look like. Recently I've been liking the looks of in-line editors though, that take advantage of the "contenteditable" HTML attribute and allow the user to literally edit small blocks of the page at a time while viewing the site. Problem here maybe that managing blocks of a page as opposed to it whole, might be a bit too complicated for you if you're new to PHP.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.