I've been trying out loads of different way to make the most effecient "template" for a site. The site consists of 'Sections', 'Menus' and 'SubMenus'. So to the question; what would be the most efficient and "slick" way of making a "template" for it? I've tried including headers and footers (Making all "head" items in the "header.php" and closing everything in the "footer.php"). I've tried using Case/Switches and includes - But all this gets very inefficient when you have a lot of redirects and pages. So I've been pondering over other sites go about in doing this..
What would you suggest that I start looking into?
Why not use a CMS system like Drupal or Joomla. Then you can take an existing template and build off of it. Drupal uses PHP Templating engine. http://drupal.org/node/11810
Related
I am thinking of running a website that sells Joomla template (similar like TemplateMonster). When I look at TemplateMonster, what come up into my mind is they have multiple instances of Joomla and they populate the content of every single of them depending on the template.
Is this the only way to achieve this? What if I have 100 templates, do I have to copy paste 100 Joomla?
These are the examples of two different contents:
http://www.templatemonster.com/demo/44048.html
http://www.templatemonster.com/demo/44129.html
Best Regards,
I think simplest way would be adding ?template=beez3 to the uri.
More complicated to use extension like Virtual Domains.
Current menu item (and so template) is set based on rules like current URI. Extension is little tricky to setup but could be exactly what you are looking for.
I am doing some freelance work for a client and I need to re-code an old menu. The entire site is static which will make this process extremely slow and redundant, does anyone have a good technique for updating multiple pages automatically?
The old developer used "Allwebmenus" which is a automatic menu creation tool. It is implemented by using JavaScript which writes HTML to the DOM. I'm going to replace this with a clean html menu and some simple jQuery.
Right now I think the best way is to create a separate .html file with the menu code, and use PHP includes on all the pages but this still requires me to update every page on the site. Can anyone give me better idea? Or do you think this is the best option?
Thanks for the help!
create menu.php and include("menu.php") into each file where the old menu's are written.
It will make your life easier going forward too.
As far as fixing all the static pages, you will have to go in and do that yourself.
include("menu.html");
You can use includes, but it might also make since to put them onto a CMS like Drupal. Handles a lot of that for you.
Using the PHP includes is a good method. If the "Allwebmenus" has Javascript code on each page, you'll have to edit each file anyways, so adding the includes is no big deal.
I'm maintaining a PHP code base that is shared between wiki websites. What I mean is that there is a single directory /web/wiki with PHP scripts that serve several websites, like wiki-devs.domain.com, wiki-public.domain.com, etc. It was written this way because all wikis look the same, and fixing a bug (or adding a feature) in one of them automatically means that all of them get the same fix/feature. The PHP code uses $_SERVER['HTTP_HOST'] to change logo of the wiki and to select the right database, etc, but all the other code remains the same for all wikis.
I'm rewriting this web project to use Smarty templates, but I can't quite understand how to make Smarty avoid serving a template (let's say sidebar.template.html) that was compiled for wiki-devs.domain.com to wiki-public.domain.com, as it doesn't know that there are multiple domains accessing the same code.
I hope you understand what I mean. Just to re-iterate: when "wiki-devs" accesses the site, Smarty generates template for "wiki-devs", but then if "wiki-public" accesses the site a second later, the same template will get served to them.
You should use the one directory for Smarty template and different compile directory for each site. This way you will avoid the problems with compilation.
For example you can use something like that:
$sitename=$_SERVER['HTTP_HOST'];
$smarty->template_dir='themes/themename/';
$smarty->compile_dir='files/compile/'.$sitename.'/';
How does Drupal 7 render out a page? What's its equivalent to an MVC's view system.
When it comes to the rendering out the final HTML page for a request, most PHP frameworks (MVC based) I've worked with take an approach where a top-level layout/page PHP file sets out the basic document structure, and then renders our various sub-views via includes or view rendering methods.
//Simplified version
Page.phtml
Head.phtml
Body.phtml
Banner.phtml
Topnav.phtml
Left.phtml
Content.phtml
Footer.phtml
I'm a little confused as to Drupal's take on this. I'm reading through Pro Drupal Development, and it starts off in similar territory with a page.tpl.php. However, it glosses over how the theme engine (is that the right term?) gets the various parts of PHP into this page (not a criticism, the book's taking an approach that different from the path I'm on).
Also, the Drupal 7 themes don't seem to have the page.tpl.php file, so its not clear (to me) where the page skeleton comes from. Also, from what I've read it seems like "Blocks" are involved, but it's not clear to me if "Blocks" makeup the entire page, or if blocks are something used selectively by themes.
So, working from high level concepts (or get as detailed as you'd like), how does Drupal 7 render out a page?
I realize you can, and probably should, start with Drupal without understand how everything ties together. I'm specifically trying to learn how the various Drupal systems come together. Apologies to people tired of reading this disclaimer!
I think there are two questions here. First, how does a single theme/template get rendered/used/displayed and second, how does the whole site come together. I think the second question has already been answered above, so I'm going to try to explain the first a bit more.
First, a module (that's why system.module exists, for all these stuff that only a module can do like implementing hook_menu()) needs to define that a specific theme function/template exists, by declaring it in hook_theme()
Speaking of that, there are two different things which can be used. A theme function, which is a function prefixed with theme_. Often used for smaller elements of a page wich have more complex logic/PHP like theme_table(). And a template, which is a file with the tpl.php like page.tpl.php
To use a theme function/template, you can either call theme() like this:
$output = theme('table', array('rows' => $rows, 'header' => $header));
Or you can use the new, so called renderable array thing. That is basically an array of data + information which theme to use:
$output = array(
'#theme' => 'table',
'#rows' => $rows,
'#header' => $header,
);
The second is preferred because it means that it will be themed as late as possible and other modules can change it in hooks. The result will be exactly the same, drupal_render() will then call theme() itself during the final rendering.
When theme() is called, it looks up the function/file to use, looks if it has been overriden the used theme, if there are so called template suggestions and then uses them.
To override a theme function in a theme, copy it to your template.php file and replace "theme_" with "yourthemename_", if it is a tpl.php file, copy it to your directory.
Now, what the final rendering process is doing is basically building up a large $page array, that is a renderable array (Some documentation of that is in hook_page_alter() and then call drupal_render() on it.
The global structure of the page/template hierarchy (which is not hardcoded, but given through whatever is in $page) is something like this:
html.php.tpl
head.php.tpl
page.php.tpl
multiple regions
multiple blocks
Almost everything is a block in Drupal 7, including the actual content, which is typically a node. A theme defines which regions it has and then you can assign blocks to it in the UI.
When trying to understand how the templates fit together, the best tool I've found is the Theme Developer module. It works a little like Firebug and allows you click on areas of a page to see the theme functions or template files that are used for various parts of the page, along with the "suggestions" that can be used for overriding them.
Templates can fit together in a variety of ways. Drupal does make some assumptions about how they'll be nested, which are reflected in the default variables that are available in the templates files. However, both the template suggestions and the available variables within them can be modified.
As I understand it, page.tpl.php has been replaced by html.tpl.php in Drupal 7.
The best description I've heard for "Blocks" is that they're what you use to display content that will be re-used in various areas site. The most common use is for sidebars, such as "Recently updated pages" lists or "Who is online now" lists.
Try take a look a presentation on How pages are built on Drupal 7 from drupalcon at http://sf2010.drupal.org/conference/sessions/page-render-drill-down-drupal-7 specially after 5 minutes from start (05:10). Sorry can't specify much detail here cause i still watch it my self. And try to understand it as well. ;)
[Update]
After watch the presentation here is my quick conclusion on how drupal 7 render out a page:
Instead of common approach that you mention from your question
where a top-level layout/page PHP file
sets out the basic document structure,
and then renders our various sub-views
via includes or view rendering methods
Drupal render a page through a rendering flow approach like this
bootstrap
menu_execute_active_handler
page_callback
delivery_callback
hook_page_alter()
drupal_render($page)
However, it glosses over how the theme
engine (is that the right term?) gets
the various parts of PHP into this
page (not a criticism, the book's
taking an approach that different from
the path I'm on).
that various parts is served starting from rendering flow number 3 (page_callback) through flow number 6 (drupal_render($page)) where its start to return an array of drupal render-able array and then latter in your theme you can use the $page variable (served from drupal_render($page)) to render i.e drupal content.
after using own custom cms for over 6 years, I decided to go for Drupal from now on. I will use Drupal for all my works. I'm pretty new at Drupal, started just 2 days ago :D
just a simple question;
I have a simple xhtml-css site (5 pages), and client is asking cms for gallery page (xhtml for now). so is it possible to make only 1 page with drupal and rest pages are using current xhtml somehow? How would I create the base with Drupal for such custom (out of Drupal) pages' links? or do I have to transfer all other html pages into Drupal as Page (drupal page)?
ps, as a new drupal user, i didnt see anything complicated as everybody complains, it is pretty well structured-clear... love it so far :) ps, i say 2 days but I had only few hours so far :)
Thanks a lot!!
The Drupal URL rewriting rules only apply to files and directories that do not exist on the file system, so as long as you avoid naming conflicts, you can put 'static' pages more or less anywhere you like, and Drupal will not interfere with them being served.
That said, it would probably be a good idea to consolidate them within a 'static' folder, either on the top level of the document root, or (more appropriate) within the 'sites' or the 'files' folder of the new Drupal install (which implies adjusting your current paths).
However, I agree with Kevin (+1) that for only 5 pages, it is probably less work in the long run to 'migrate' them to Drupal right from the start, as you will save work and trouble down the road as soon as you further enhance the site.
If its only 5 pages, why not put it all into Drupal? Less overhead that way. Otherwise you will have to edit .htaccess, manually update files instead of making simple changes in Drupal, and edit multiple files should the theme change in any way.
If you need a Gallery solution, I would suggest checking out the Gallery Assist module.
If all 5 pages use the same or similar layouts, navigation, etc then it makes the most sense to put them all in Drupal.
Setting up, configuring, and theming Drupal will be a lot more effort than one page is worth.
But if all your content does not share a similar layout and have very different looks then you may consider leaving them static.
There are many ways to vary the the layout, navigaiton, and such within Drupal, but this may be a challenge for a Drupal beginner and even require a substantial effort from Drupal pros.
If you leave content external to Drupal that includes identical layout elements, it leads to redundant work.