I am creating a website for a local company and I am splitting off the header for each page into a individual php page which I then include into each page. I was wondering what would be the best practice to insert individual description and title content into the php header for each individual page. Should I create a php variable before the included header.php link and then insert that variable argument into the title and description tags in the php file? Each variable would have different titles and description depending on what page it's on. Or would it make more sense to someone include these different description and title content into another external php page? If you have a even more correct/easier way that would also work best with SEO please let me know. Thanks!
I would suggest creating a Metadata object definition, with all of the properties required (description, tags, etc). Then instantiate a Metadata object for each page of the site, just before including your header, and use the values of the current Metadata object in the header.
split your logic (and titles, page information, dynamic content) from your templates via an MVC type architecture
here are some easy to learn templating engines (and I believe the two most popular)
http://www.smarty.net
http://twig.sensiolabs.org
You can read about MVC architecture here: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
However you do it, basically what you suggest initially is one of the best ways. Define a variable, or object, or whatever, in each page before the inclusion of the header.php file (again, whether that's a template, or just a regular php inclusion, up to you). Then just set them to whatever you want for each page, and you're good to go.
Personally, I would recommend using a template engine like Smarty.
As for SEO, that's an entirely different conversation. That's more related to the content of the variables, as opposed to the implementation of them.
Related
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. ;]
I have a medium size legacy php application with almost no javascript integration. I've recently been learning javascript (yes actually learning it) using Douglas Crockfords excellent book and taken YUI as my library of choice. I've tried out a few things and got a few things working but now I want to integrate the various components etc into my application properly, my question is how to go about doing this for ease of maintenance and code reuse.
Currently the application consists of
php pages
smarty templates (html templates with some special template markup) for each section of a page so multiple templates may be used for a single page.
single css file.
I have the following ideas about how to integrate my javascript into the pages.
Write inline javascript in each smarty template with the code required for that section.
Write a seperate .js file to go with each smarty template that is linked in and then a single inline script to run it.
a seperate .js file for each php page which would have all the functionality required for the entire .php page. A small inline function would call whatever functions were required.
Something I havent though of?
Does this make any sense? Does anyone have a good suggestion for this?
Update:
One extra bit of info is that its an internal application, so its not so important to restrict everything to a single file.
Two other options:
A single JS file that contains all the JS for your entire site. Depending on your caching settings, you should be able to get the user to download just one file for the entire site and use a cached version for every other page.
Divide your JS up according to function, rather than page, and include whatever functionality each page requires. E.g. one page may require tabs, form validation and animation, while another may only require tabs.
Or you can have a hybrid of these: one JS file that contains the vast majority of your code and an extra file if needed for particular pages or templates.
None of the approaches mentioned are wrong (though I'd skip the inline JS one as much as possible); which one is best will depend on your precise situation and your personal preferences.
Firstly, most setups allow a master layout template in which you can place a common page opening or, alternatively, each template includes some global header.
That being said, you should do a combination of 1, 2 and 3:
Have a .js that is included in all templates that contains global functionality. Each template may also optionally have it's own .js specific to that page or section of pages. Finally, if there's tiny amounts of code specific to a page (or must be dynamically generated each time), it won't make sense to initiate another http connection for it so have that source be right in the template.
if you don't have a ton of javascript then create an external js file and include it in the header of the webpages and be done with it.
I'm working on a site in php. Originally I had a lot of html pages but they were all very similar in that they had a heading, an image, and some text. I was able to consolidate my pages into one php page and pass in the heading and image name as GET variables. I wouldn't want to pass a lot of text this way though. What's the best way to do this? I was thinking of including the text from a text file but then I'd have a text file for every item. I also thought that I could have a database and read the text from there. What do you guys think?
According to me, it is better you use the database and just pass the ID's, through the $_GET.
You can divide your page in three sections.
header.php // including all the header section
body.php // your main content, varying according the $_GET
footer.php // footer section
Thanks.
pass in the heading and image name as GET variables
This is probably not secure. And its a bad coding practice to rely on GET's for your page structure. Why not use includes?
As for storing the data, the database is the way to go, flat files suck.
So, you could pass a unique ID for the text, and always include your header and footer:
include_once('header.php');
//If the id is valid, use it to query the text from the database.
include_once('footer.php');
You're right, using GET variables is inconvenient. It is also very insecure, since an attacker could trick a user into following a link which would inject HTML into the page, which could then pass the user's cookies to the attacker.
The most common approach is to store the various content blocks in a database such as MySQL. See the PHP MySQL docs to get started. You can then set up a simple form or WYSIWYG editor such as TinyMCE to allow the site administrator to edit content.
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.
I'm starting to understand the importance of templating in PHP. I'm using PHP itself as a template engine to avoid learning any new language. I'm still not clear on one thing tho, although I have an idea about it. I would like to know what the experts do.
Should I create a full page template, with all tables, forms and everything else (including header and footer), or should I put all of my tables, forms, etc in their own file and then add them to the template as needed.
Here's a small example to clear things up...
Should I
a) create one page with all the tables, forms, and other elements in it and use that as a final product
// Set all the information
$template->title = $username;
$template->user_info = get_user($user_id);
$template->articles = get_articles($user_id);
$template->ads = random_ad($user_info);
// Load the template with everything already in it
$template->load('user_page.tpl')
$template->display();
OR
b) create every table, form, related block element in its own file and then use those to create a final product
// set the title and load the header template
$header['title'] = $username;
$template->load('header.tpl', $header);
// get the user info as an array and load into user profile template
$user_info = get_user($user_id);
$template->load('user_profile.tpl');
// load the new article form
$template->load('new_article_form.tpl');
// get the articles as an array of info and load into user articles template
$articles = get_articles($user_id);
$template->load('user_articles.tpl', $articles);
// get a random ad based on user info
$ads = random_ad($user_info);
$template->load('advertisements.tpl');
// load the footer template and display final page
$template->load('footer.php');
$template->display();
Where every file loaded contains a small portion of what needs to be displayed on the final page.
Because of the Dont Repeat Yourself technique, I would think B, but i would like to know which and why
I would personally say the first approach is best, because it keeps all documents and document fragments semantically complete.
The second approach means that you'll have a <div> in your header.tpl that is closed by a </div> in your footer.tpl (except likely there will be a few tags that applies to). This means if you change your layout, by adding a wrapper div (for example) somewhere, you have to remember to also close it in another file (or, depending on your layout, two or three different files).
It's worse with several different embedded files. Think of how hard it is to debug a site, when one file - that gets included conditionally - has an extra </div>. You get a vague bug report "sometimes the page looks completely messed up, doesn't matter what browser I use" that is very very hard to track down. It's MUCH worse if you're using table-based layouts..
Using the first approach, you can still use the DRY principle. You load the template into a variable. eg:
$userVars['name'] = $currentUser->name;
$templateVars['userinfo'] = $template->load('userinfo.php', $userVars);
...
$template->display('template.tpl', $templateVars);
You can continually nest documents that way. There are many benefits:
Each file is semantically complete HTML - all tags that are opened, are also closed in the same document. It's easy to edit one part of the layout without breaking (possibly unknowningly) anything else.
It's each to cache the output of certain templates, and re-use them
It's easy to apply AJAX to the site. For example, you have a stats.tpl template rendering inside a <div id="stats"> on the first page load. You also have a view that just renders the stats.tpl template by itself, and then use jquery to do $('#stats').load('/ajaxstats.php'), which refreshes that div but without repeating code at all.
Template inheritance for structures common to every template (e.g. layout; header/footer), and template embedding (i.e. including) for reusable bits (e.g. forms).
With approach A and without inheritance, you'd be either including common layout elements (which is IMHO ugly), or duplicating entire layout in every template (which is even worse). And plain approach B would create massive amounts of tiny template bits for everything, which may reduce maintainability.
And for that, I really recommend using real, dedicated templating engine instead of plain PHP. They make life easier (inheritance is one thing; another - variable auto-escaping).
template inheritance would probably make the cleanest code. you can do this now in straight php using PHP Template Inheritance
There is no good or bad solution. There are techniques and guidelines but in time you will learn what approach is better than others.
Just by looking at it i would say that the second approach allows you to be more flexible and breaks down the page into smaller parts. Smaller might some times mean more manageable.
Also the second solution also allows more than 1 persons working on the page since they will only need to work/change parts of the page and not the whole page.
regards,
As gregmac suggested, the first solution is probably preferable. Having said that, I would also suggest to have a look at the various PHP frameworks available, most of which implement templates using various techniques.
Have a look at this list for a start. You may also want to take a look at some stand-alone template engines, such as Smarty, in order to get some ideas or to avoid implementing your own engine.