So, currently I'm organizing my blog based on filename: To create a post I enter the name of the file. As opposed to storing the post in the database, I store them in PHP files. So each time I create a post, A new row in the table is created with the filename and a unique ID. To reference the post (e.g. for comments) I get the name of the current file, then search the entries table for a matching file name. The post ID of the comment matches the ID of that post.
Obviously this isn't the standard way of organizing a blog, but I do it this way for a few reasons:
Clean URL's (even cleaner than mod_rewrite can provide from what I've read)
I always have a hard copy of the post on my machine
Easier to remember the URL of a specific post (kind of a part of clean URL's)
Now I know that the standard way would be storing each post in the database. I know how to do this, but the clean URL's is the main problem. So now to my questions:
Is there anything WRONG with the way I'm doing it now, or could any problems arise from it in the future?
Can the same level of clean URL's that I can get now be achieved with mod_rewrite? If so, links are appreciated
I will be hosting this on a web host. Do only certain web-hosts provide access to the necessary files for mod_rewrite, or is it generally standard on all web-hosts?
Thanks so much guys!
P.S. To be clear, I don't plan on using a blogging engine.
As cletus said, this is similar to Movable Type. There's nothing inherently wrong with storing your data in files.
One thing that comes to mind is: how much are you storing in the files? Just the post content, or does each PHP file contain a copy of the entire design of the page as opposed to using a base template? How difficult would it be to change the design later on? This may or may not be a problem.
What exactly are you looking for in terms of clean URLs? Rewrite rules are quite powerful and flexible. By using mod_rewrite in conjunction with a main PHP file that answers all requests, you can pretty much have any URL format you want, including user-friendly URLs without obscure ID numbers or even file extensions.
Edit:
Here is how it would work with mod_rewrite and a main PHP file that processes requests:
Web server passes all requests (e.g., /my-post-title) to, say, index.php
index.php parses the request path ("my-post-title")
Look up "my-post-title" in the database's "slug" or "friendly name" (whatever you want to call it) column and locates the appropriate row that way
Retrieve the post from the database
Apply a template to the post data
Return the completed page to the client
This is essentially how systems like Drupal and WordPress work.
Also, regarding how Movable Type works, it's been a while since I've used it so I might be wrong, but I believe it stores all posts in the database. When you hit the publish button, it generates plain HTML files by pulling post data from the database and inserting it into a template. This is incredibly efficient when your site is under heavy load - there are no scripts running when a visitor opens up your website, and the server can keep up with heavy visitation when it only needs to serve up static files.
So obviously you've got a lot of options when figuring out how your solution should work. The one you proposed sounds fine, though you might want to give careful consideration to how you'll maintain a large number of posts in individual files, particularly if you want to change the design of the entire site later on. You might want to consider a templating engine like Smarty, and just store post data (no layout tags) in your individual files, for instance. Or just use some basic include() statements in your post files to suck in headers, footers, nav menus, etc.
What you're describing is kind of like how Movable Type works. The issues you'll need to cover are:
Syndication: RSS/Atom;
Sitemap: for Google;
Commenting; and
Tagging and filtering content.
It's not unreasonable not to use a database. If I were to do that I'd be using a templating engine like Smarty that does a better job of caching the results than PHP will out of the box.
Related
I have partial understanding of why a developer will have a filename like afs342sf.css opposed to something more readable like main.css - I do not believe that the developer named the file manually; I'm sure it was done programmatically upon insert into whatever database. I'm a bit baffled on why this would be needed, and how it will be called.
If a database has a table with, and excluding others for simplicity:
file_id, file_name, file_display_name, file_size.......... etc.
When called for data it's using file_display_name (afs342sf.css or simply afs342sf) as a reference - href="/yourhost/www/afs342sf.css" - what on earth is the difference when someone can easily use the same GET request info, or have I got this theory all wrong? - I'm a paranoid one typically (apparently good for security) and have confused myself because it could also be the id for it, but isn't that giving away too much? Then there's the thought of what if the program changes the filename upon every request; could it get lost when other requests are incoming, and it doesn't have a fixed address name?
Last but not least, I would much appreciate it if anyone could post any links to pages that could help with stealthy, or concealed file retrieval methods. For the record I do not hide the .php extension - being self taught and learning from a trusted community is overwhelming for knowledge.
You're right, it's not named manually. Arbitrary filenames like that usually mean they are generated with a tool like Assetic. This is primarily used for files that have to be converted before being put on the web (SASS to CSS; Coffeescript to Javascript).
Assetic also has a cache-busting plug-in that generates filenames based on the hash so when the contents change, browsers will be forced to fetch the new file (this is a standard cache-busting technique). This is useful because static files usually have long expiry dates, and there's no other way to alert the browser that the file has changed.
I'm creating my own CMS from scratch as a way to build my php and mysql skills. Everything is going well, but I'm at the point where I want to create individual post pages for each blog post I write. So the index.php page has a list of all my blogs with snippets of each post and there is a read more button that should take the user to the full page for each blog post. Each post has a url created from the blog title entered in the "create post" form. I'm trying to figure out how to create unique pages for each post without passing the title, subhead, post content and other info through the GET.
This also dovetails with another feature I'm trying to add. I want to be able to create individual pages using a "create page" form like I did for my posts. So if I want an "about us" page I go to my admin form, fill out the title, add the content, and when I hit submit it creates the page dynamically. I have thought all day about how I'd do these two things but can't quite figure out how I can do this.
FYI, I'm not asking for code, I just need a push in the right direction as I try to conceptualize how to achieve this. Thanks!
If you're not familiar with the Model-View-Controller pattern, reading up on it might be prudent. MVC is frequently the right starting place for high-level design of web applications.
Also, a CMS is a big enough project you should consider using a PHP framework like CodeIgniter, Symfony, Zend, etc. to make your life easier. It removes a lot of the drudge work and common tasks.
Dynamic Page Creation and Display
I think you want to split it into two things: the text content (basically what you put in the forms) and the HTML templating surrounding that content.
When you make a page or blog post, you would want to store the actual content (what you type into the creation form) in a database of some sort (not necessarily an RDBMS, but if you're trying to build MySQL skills it's a reasonable choice).
Then you would use a separate function to bind that content into an HTML template and present it to the user when they load a given page.
URL Routing
To get nicer-looking URLs you can use something like apache's mod_rewrite. You can use that to convert a URL like this:
posts/how-to-make-a-cms
to this:
posts.php?title=how-to-make-a-cms
Then you can have posts.php read from GET as normal. How you choose to do the conversion is pretty open-ended.
To avoid getting really complicated rewrites, people often just structure everything to go to a central routing script which figures out what class and method to call and what arguments to pass it. So it would rewrite the URL above to:
main.php?a=posts/how-to-make-a-cms
Then main.php would parse out the segments of that argument from GET and figure out where to send them. Like it might take posts/show/how-to-make-a-cms and do something like:
$o = new Posts();
$o->show("how-to-make-a-cms");
If you do it that way, I think you can avoid mod_rewrite entirely as long as you're willing to accept only slightly pretty URLs, like this:
mysite.com/main.php?/posts/show/how-to-make-a-cms
I haven't done this type of thing before (because the frameworks do it so beautifully already), so I might be missing some minor details.
You should watch some tutorials from phpacademy.org or thenewboston.org, they have best and most valuable tutorials ever made about PHP.
I think you may try to start from that course/playlist:
phpacademy.org: PHP Tutorials: Creating a Blog
If you don't understand everything, watch this:
thenewboston.org: Official Beginner PHP Tutorials Playlist!
If you have no problems with PHP itself you may try to use some simple framework with MVC support. That helps A LOT in variable handling between pages, makes work with database easier etc.
phpacademy.org: Introduction to CodeIgniter
phpacademy.org: Introduction to CodeIgniter - Basic Website
I had the same problem. You can easily do this by using the fopen function. Here is a link to a tutorial: http://www.tizag.com/phpT/filecreate.php
<?php
function wwwcopy($link,$file)
{
$fp = #fopen($link,"r");
while(!feof($fp))
{
$cont.= fread($fp,1024);
}
fclose($fp);
$fp2 = #fopen($file,"w");
fwrite($fp2,$cont);
fclose($fp2);
}
//Example on using this function
wwwcopy("http://www.domain.com/list.php?member=sample", "sample.html");
//Another example
wwwcopy("http://www.domain.com/list.php?member=sample2", "sample2.html");
?>
I'm setting up a website where visitors will be greeted by a splash screen where they will choose a color scheme for the actual website; based on their selection, the actual website will load with a different stylesheet. I gather this can be done by concatenating a flag to the URL, then reading the flagged URL on the next page to determine the stylesheet to be loaded (for example, to load the dark theme, the url would become http://www.mywebsite.com/index-dark; clicking the light theme link would make the URL http://www.mywebsite.com/index-light. Problem is, I don't know how to add a flag to a URL, or how to read this flag on a different page. I've tried Googling the issue, but have found little practical information. How can this be done?
EDIT: I'd like to avoid using two separate pages, as I'll have multiple themes; that would mean copying basically every HTML page in my root multiple times, taking up space. I like the idea of a concealed $_GET variable, though.
Without more information, I can only give some general advice.
So I'm going to assume that you are building a page in PHP, so you could have two different urls and use mod_rewrite to convert /index-dark to /index?style=dark but that's crappy.
What you probably want is to use a cookie or a session. Basically you check a cookie, or session value, for the theme setting and then pick the appropriate CSS file when you generate the page.
This has several advantages:
Doesn't require using url rewriting, an error prone endeavour at the best of times
Allows for persistent setting (if you use a cookie) and doesn't involve complicated urls.
Allows for adding more themes without changing mountains of code, just add the setting to theme selector and the new CSS file.
GET variables are generally only useful for specific data sent with that request, a bit like POST variables are mostly for forms and submitted data. If you want persistent settings, then a session/cookie is the best option.
The "flags" you're mentioning are probably actually $_GET variables that have been disguised using mod_rewrite. What you can do is edit your .htaccess file to add in rewrite rules that change, say, www.mywebsite.com/index.php?style=index-dark to www.mywebsite.com/index-dark (unfortunately I don't have experience in how exactly to do this; I just know that it can be done) and have your PHP catch $_GET['style'].
I was having a "discussion" with my manager today about the merits of using PHP includes and functions as a template to build websites more quickly and efficiently. He has been using Dreamweaver templates for years and sees it as really the best way to go. I would like to start using some different and more efficient methods for web creation, because we need to get through our projects faster. I would like to know in detail what would make Dreamweaver dwts better than using code to accomplish the same task, or vice versa.
His reasoning is:
When you change links on the dwt file, it changes links for every page made from that dwt.
Even if you move pages around in directories, it maintains links to images
Everyone in the company should do it one way, and this is the way he chose (there are two of us, with someone who's just started who needs to learn web design from the beginning, and he plans to teacher her the dwt method)
If you edit a site made with a dwt, you can't change anything in the template (it's grayed out), making it safer
If he's building sites with dwt, and I'm doing it with PHP includes, we can't edit each others' sites. It gets all over the place. When we have new employees in the future, it will get all crazy and people can't make changes to others' sites if they're out of the office.
I've been studying PHP these days, and am thrilled with how powerful it is for creating dynamic pages. The site in question which sparked this "discussion" is more or less static, so a dwt would work fine. However, I wanted to stretch my wings a bit, and the code was getting REALLY jumbled as the pages grew. So I chopped off the header, footer, and sidebar, and brought them in to all the pages with a php include, as well as dynamically assigned the title, meta data, and description for each page using variables echoed in the header.The reasons I like this better are:
It's cleaner. If every page contains all the data for the header and footer, as well as the extra tags Dreamweaver throws in there, then I have to sift through everything to find where I need to be.
It's safer. It's sort of like the above reason dwts are safe, except I do all my code editing in a text editor like Coda. So on occasion I have accidentally deleted a dwt-protected line of code because those rules only apply within dreamweaver. I can't chop off part of the header if I can't see it. Incidentally, this makes it easier to identify bugs.
It's modern. I look through source when I see great pages made by designers and design firms I admire. I've never seen dwt tags. I believe by using PHP to dynamically grab files and perform other tasks that keeps me from having to go through and change something on every page, life becomes easier, and keeps things streamlined and up-to-date with current web trends and standards.
It's simple. This should be at the top of the list. Like I said we have to train a new person in how to create for the web. Isn't it much better for her to learn a simple line of PHP and get an understanding for how the language works, rather than learn an entire piece of (not exactly user-friendly) software just for the purpose of keeping her work the exact same as everyone else's? On that note, I believe PHP is a powerful tool in a web designer's arsenal, and it would be a sin to prevent her from learning it for the sake of uniformity.
It's fast. Am I mistaken in my thought that a page build with header and footer includes loads faster than one big page with everything in it? Or does that just apply when the body is loaded dynamically with AJAX?
I did extensive searching on Google and Stack Overflow on this topic and this is the most relevant article I could find:
Why would one use Dreamweaver Templates over PHP or Javascript for templating?
The answer is helpful, but I would really like to understand in more detail why exactly we shouldn't switch to a new method if it's simpler and has more potential. My manager insists that "the result is the same, so if there isn't something that makes me say, 'oh wow that's amazing and much better!', then we should just stay how we are now."
(I do apologize for the length of this question, but the guidelines asked that I be as specific as possible.)
Like I said in comments, without knowing what exactly sites you are working with it's hard to tell which PHP features are most important to showcase. However, I can try and describe the most simple kind of sites I was dealing with, and where and how PHP came in handy. If you work with something more complicated, the need of programming language may only increase.
The simple website may have a few different pages with text and images. I'm assuming nothing interactive (i.e. no inquiry form), no large amount of structured data (i.e. no product catalog), only one design template which is used by every page with no differences whatsoever. Here's the typical structure:
One PHP file (index.php) for handling all sorts of php-ish stuff
One design file (template.php for example) for storing everything html-ish (including header, footer and more. Basically all html with placeholders for text and menu)
One CSS file for, well, the site CSS
Most of the texts are stored in database or (worst case) just txt files. Menu (navigation) is stored in database as well
Images folder with all the needed images
The key features here are:
Simplicity. You only have as many files and code as you really need to keep things organized and clear
Reusability. You can basically copy/paste your php code with little to no changes for a new similar website
No duplicates whatsoever.
Data and design separation. Wanna change texts, fix typos? You do it without as much as touching design (html) files. Wanna make a completely brand new design for your website? You can do it without even knowing what those texts are or where they are kept.
like deceze said, no lock-ins. Use whatever software you like. (Including Dreamweaver)
PHP is responsible for taking texts, menus, design and rendering them all into a web page. If website is in more than 1 language, PHP code choose the right texts for the language of visitors choice.
If texts are stored in database, you don't even need notepad and ftp. You just need, i.e., phpMyAdmin (stored in server) so you can connect directly to database and edit any text you like using only web browser; from anywhere in the world. (I am assuming no real CMS). If you need to add one more page, you connect to database using myAdmin and browser, enter the page name (for menu) in 1 or more languages, enter the text for new page (in 1 or more languages), done! new page created, name placed in the menu, all hyperlinks generated for you. If you need to remove a page, you connect to database and click delete. If you need to hide a page for a while (i.e. for proof reading before publishing), you connect to database and uncheck "published" box.
All this doesn't come with just using database ofcourse, you need to program these features with PHP. It may take about 1 - 3 hours depending on experience and the code is fully reusable for every similar website in the future. Basically you just copy/paste php file, copy/paste database tables, enter new text and menu into database, put placeholders into your html file and done! brand new site created.
Which immediately makes most of the reasoning for DWT irrelevant. You don't move files around because you have only one html file and no directories, you don't need grayed out template because texts/images (content) and template are not even in the same file, there's no such thing as changing links in dwt file because it's PHP that generates them on the fly (these are not real links to real html files but rather links with parameters to tell PHP which exactly page must be rendered.. because remember we have just 1 file). The bottom line is, comparing features of the two side by side is like comparing features of a sword vs machinegun. Sharpness and length of the blade concepts are meaningless in a case of machinegun; while lifetime sword user won't really get the meaning of velocity and caliber before he tries and uses machinegun. And yet, while you can't compare their features one by one, no one brings sword to a gunfight for a reason :)
As for #3, currently there are many more people working with PHP than DWT (in a case you will need more employees in the future, or if other people will need to work with your websites later, etc.) As for #5, you can edit PHP websites with Dreamweaver as fine as DWT websites.
That's just off the top of my head. I wrote this in my lunch break so I likely forgot or missed quite a few things. I hope you will get a proper answer with detailed DWT vs PHP comparison too.
You simply can't compare PHP vs. DWT.
PHP is a programming language, where templating is just one of it's numerous features, and DWT is just a silly proprietary system to build simple web pages.
there is actually nothing to compare.
I would say that using DWT templates over PHP do have some advantages.
It does not need any extra server-side process, like PHP to process the files at the server.
You can serve all files to the user as .html files rather than .php files, though I suspect that it is possible to hide the .php extension. Why should any user see anything other than .html?
You don't have to learn PHP syntax/programming. It is true that you can do more with PHP that plain .dwt files but for plain templating the .dwt files can be just as clean.
It is not true that .dwt files are a lock-in technology. The feature is also implemented by other web editors, e.g. Microsoft Expression Web.
I want to understand how to use templating system and permalinks on php websites :D !..
let me describe my self more,
1.currently i have 20 files each have its own php logic (index.php,wizard.php,search.php etc)
ALL use same class's and includes.(install.php include all the required for all class's in my project abd u require_once(install.php) in all files)
i wana remodel my website into.
Analyze URL requested ---> IDENTIFY requested page ---> GET TEMPLATE for THIS PAGE -->MODIFY header(meta) and footer(javascript) ---> add logic ---> display page :D.
can some one put me on right learning track :D !. cuz i hv coded my website fully in oop and made all its content loads dynamically from MYSQL (simple small CMS) but i have no clue how to join template and php into index without repeating my self and create different file for each page in my web ! (each file do different jobs of course like file users.php does login and registration and userprofile etc)
Hope my english wassnt too too bad and u could understand my question :D !
My current approach so far:
Mysql table : page_tbl
columns: pagename,LogicFile,templateFile,MetaTag.
index.php?pagename
will check if not already cached or not listed for chacing it will :
Mysql:SELECT * WHERE pagename='$_GET['page']'
loginfiles = cars.php,search.php (will be exploded with , and included)
Template files = will be also exploded and modified according to MetaTag.
Metatag: Serialized assoc array with ['name']=['value'];
Then i start buffer output , replace template with new descriptions and keywords(auto generated)
include logic files
include footer.php (which include the scripts)
am i near to correct rout or still far away ? or am did i lose my track and over killing
If you are unsure whether you want to write your own, or use an existing one.
It is going to be a quite possibly very rewarding experience but a very time consuming one to write your own.
If you have a task at hand that you need to be solved, use an existing one.
That being said there are plenty of templating systems, smarty being the most long-lived one. You can find a short discussion on 5 popular ones at phpbuilder.
You also have entire Frameworks that you might want to consider. They are more than just a templating system, where database stuff, ajax helpers etc are included. Zend, CakePHP, and Codeigniter being popular ones. You can find comparisons of these at phpframeworks.
The best way is to take this route:
parse request data
determine controller which will be used
in controller select layout and template [layout "includes" template, it hold the contents that are common to all pages and template has the request-specific content]
in controller also fetch the data from database [MVP way]
assign data to array and pass it to the layout, it'll pass the data futher to the template
in layout and template use data from that array and construct view
pass everything to the browser
This is the way the frameworks work, and it isn't that bad. ;]