I'm a little new to drupal but have been using things like devel module and theme developer to speed up the learning process.
My question, is it possible to theme an entire views BLOCK from a single views tpl.php page OR even a preprocess?
When I'm grabbing the $view object I can see results $node->result, it has all of the results, but it doesn't have all my views fields. I'm missing things like, node path, taxonomy titles and paths, etc.
From my understanding, Drupal wants you to individually theme EACH output field. It seems rather superfluous to create so many extra templates when I've already got over HALF of my results coming through the $view object
Would outputting node over field make this easier? Or am going in the wrong direction with $view->result?
Thanks!
this page might help: http://drupal.org/node/342132
I rarely theme at the views field level -- agreed: it's too many files to edit. So I either do it at the node/teaser level, or load the view programmatically, and then display it in a function in my glue module.
whether to do nodes or fields depends on how else you're displaying the items. for example, if the only way you're using teasers is in this view, it might simplify things to do the theming in the node-mytype.tpl.php file. If you have four different views, all of which have different themes, you might use the glue module approach. There's also the css-only appraoch. Or, sometimes, views theming truly is the best option.
update: you can also use node_load in your glue module to get more node info. That can be expensive, performance-wise, depending on the size of your view and how often the nodes change. (node_load does some caching...)
Related
So I am making a CMS, a gallery script via Object Oriented PHP. Anyways, the problem is now that I have the basic layout for the objects and such to the point where I need to start putting together, I am stumped how to do this.
What I have is essentially a Navigation, Data, Gallery, and Module class. Module stands for pages, categories, et cetera. The problem is that Gallery outputs the images, module gives the data for the pages, navigation creates the (you guess it) navigation. You get the picture.
On the index page, I end up doing essentially this (this WILL change, but it is illustrative for how I was starting to set it up):
$navigation = new Navigation();
$navigation->top();
$page = new Module();
$page->basicPage($_GET['m']);
The basicPage() does a few things, but primarily this is the issue:
$gallery = new Gallery();
$gallery->setGallery($id);
$gallery->thumbGallery();
So on so forth.
The problem arises in that if I call basicPage(), the designer or whoever has very little control over the choices. As you saw, it is thumbGallery, and that doesn't allow full images, and it doesn't even let you set the size of the thumbnails (which I do let them do, only if they can call that function them self though).
So I thought of a few solutions to the problem. I don't have these basic pages, but I have the designers build out templates much like wordpress. I dislike this solution, because it makes the design process complicated, albeit thorough. I don't want to make it so that everything is controlled, and is one way. Of course you can "display: none" to elements as the designer and a few other tricks, but I want them to have the ability to do a lot of things, without the complicated way that Wordpress does it.
My question is how do I strike the balance between simple and flexibility?
Any help, even ideas are appreciated. Thanks.
EDIT: I forgot to mention. The problem is from just having the index have all of this data is otherwise I will have to do a lot of if/else and such, and I really didn't want to make this a procedural program, just one you can essentially just plop stuff down and we're good. See, module stands for both gallery and page. Most pages will not have images attached to it, and the categories will have images, but not always text. It will cause an error if I call thumbGallery and it is just an informational page, and if I call an informational page and it is a category, it will not show the images (to avoid the error). I could, and have started to build it together in what is called basic page,but the problem like I noted before is that it restricts how much freedom the designer has without having to mess with php, and most designers are pretty dumb when it comes to php, unfortunately. Espectially OOP (no offense. I am a designer too, but I happen too program).
Without seeing the rest of your code it's difficult to know the best solution considering what you already have. I've developed my own custom CMS Application Frameworks from scratch for the past 9 years, and I'd be glad to give you some tips.
I'm assuming you're storing all the CMS content in a database. Storing the configuration for the gallery settings in the database might be a possible solution. In theory you should have different views (following the MVC pattern) for displaying the gallery in different ways. A listing view for showing multiple image thumbnails, one for showing a single image, plus a view to list categories perhaps.
So, in the database you could define that page X should show the thumbnail view instead of a category view.
Not sure if that's a solution to the problem you have, but that's a very simplistic example of how I've done it in my CMS's in the past.
I was looking other day jealously at all the features that CMS-enabled WordPress sites have, and I realised one thing that I've missed out: tagging.
Is there any way I can have such a thing on my non-cms, non-database flat files php website? Which is basically bunch of web page files like home.php, contact.php, somepage1.php, somepage2.php, etc.
is this actually possible at all?
I was thinking of something like this:
each page includes tagsys.php
each page has footer with some tags banana, peach, tomato
the hyperlinks go respectively to /tags/banana, /tags/peach, /tags/tomato
since there are no actual files as banana / peach / tomato, the tagsys.php which is included, has to know how to sort of generate a new page, in which it captures the essence ($title and $descr) of every page with that tag, and so all could be automated.
You could also add an id to each page (it may be the filename, wich you can get using php : http://www.expertcore.org/viewtopic.php?f=67&p=1453)
Then in your DB store create a table with a list of tags and another one to create a relation between your pages IDs and the tags.
In this way you will be able to create a kind of "tag administration interface" easily.
But as Brent Friar said, if possible, prefer upgrading to an existing cms, it's quite fast and easy, and it'll save you hours of maintenance!
It would be a lot easier, faster, and less headache to simply upgrade your website to any number of CMSs that support tagging. Even if your site has several hundred pages it would not be hard to move it to Wordpress (though I would use a more sophisticated CMS, WP is a fine product that is easy to use).
Keep in mind that on a static site you are going to have to update the tag associations every time you create a new page. It would be an administrative nightmare.
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.
I am building a web application in which the user may add a page, edit the layout, drag drop element, resize element, format the text, edit the element attribute etc.
In the page the user may include (retrieve) dynamic data, like maybe data from database, data generated by php code, etc.
I have played around with cakephp and jquery lately and tried to build this app. But I stumbled upon on how to appropriately display the php code. I tried to look into the cakephp core code and find about output buffering and tried to utilize output buffering to parse the php code and use regex to display it but it is more likely to reinvent the wheel if I write the parser my self
What I am asking is:
Ok, to be more simple and specific I just want to ask, how to save and load the page that was created by the user especially if the page contains php code. I just want to know is there any other method than write my own parser or maybe a library to parse a php code?
Ok that's all for now, does anyone have any idea how to implement it? Or maybe any page / website that could be useful to take some reference from? Maybe a sample code from which I can take some reference
Thanks
I'm not sure you'll find any good answer here about that.
Whoa I don't know where to start. I'll start by the number 3. You want widgets. Then that means you have to create widget class or objects that possesses a template or something that makes them drawable "well, kinda". If I were you it would be loaded from javascript and not really from php. Each widget would be in some way individual applications loaded in a div using javascript.
Point 2, You wanted widgets. When you add widgets to your page, you have to save some informations, like Position, Title, dimensions and so on. You may even save creation parameters. For exemple a ListWidget may be started with different ItemProvider. That way you don't have to write 1000 widgets but only one that shows different content. That said you have widgets, dimension and position. Now that lead us to point 1.
Point 1. Once you have your widgets, position and dimensions, you send the data you used to create them associated with the page to the server. That lead us two point 2 again.
Once you have saved a page. You can see it by retrieving all widgets with parameters and so on. That leaves you 2 options.
Generate Javascript that will recreate the saved widgets.
Generate Html will all the widgets.
Option 1 is simpler since option 2 won't bind html to javascript by itself. Solution 2 on the other hand is better since there is only 1 request to the server.
Oh and a last thing, You should set yourself some limits. That kind of thing can get very complicated and unfortunately not that great. See drupal for example. It does lots of cool stuff but as soon as you install lots of module. Drupal transform itself in some sort of memory eating monster. And almost all the time you don't really need that much of dynamic content. Fixed layouts will do work nice almost 99% of the time.
I'm also forced to say that but if you try to create an application that give users as much power as a scientist that could raise a 7 legged cat. I think you're going to play with really obscure forces!
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.