Given that I have a URL to a page and I can see the content on it as a user, is there a simple way to find out what template files are producing the page? Ideally I would like to know three things:
The current template file(s) being used
The filename(s) I can create in the local folder to customize them
What variables are available to these file(s)
I just want to know what the general procedure is for finding this information out.
The devel_themer module includes a theme developer function that'll let you click anywhere in the page and determine what templates, theme functions, etc. are used (or can be used) to generate an element.
You can use PHP's get_defined_vars() function to get the variables available in a particular template or function.
Related
I am trying to construct a Web site with blogdown, Hugo, and the xmin theme. I would like to store some Markdown files in a subdirectory, say content/misc/, such that they are not going to be treated as blog entries (e.g., they will be pointed to specifically on some _index.md pages).
How can I do this for single files or for all files in a subdirectory of content/? I know I can kind of hide them directly in the content/ directory, however this makes structuring the project clumsy and difficult.
I suspect this will be possible with specific templates, but is there an easier, much simpler way to handle this requirement? Or are there more appropriate themes to make it possible?
If there are some pages that you want to show with a common format, but you do not want them to be listed in your blog articles list
Simple solution: use the default template
To use the default template, you just need to add this "misc" folder in "content" with all your Rmd inside. Then, there will be a page listing all the articles of this type at "myblog.com/misc/".
Advanced solution: use a specific template
If you want to have a specific template for these pages.
If it does not exists, create a "layouts" folder at the root of your project.
Inside "layouts", create a "misc" folder
Inside "misc", create a "list.html" file if you want that your page "myblog.com/misc/" shows a list of your pages with this category
You also need to create a "single.html" if you want a specific way of showing these single articles.
To have ideas what to put inside these two files, you can directly start with the template of your own theme (https://github.com/yihui/hugo-xmin/tree/master/layouts/_default). As I said, you can also look at the "itemized" type of "hugo-future-imperfect" (https://github.com/statnmap/hugo-future-imperfect/tree/master/layouts/itemized), or what I propose for sticky pages on "hugo-statnmap-theme" (https://github.com/statnmap/hugo-statnmap-theme/tree/master/layouts/sticky_pages)
I know that the difference between a theme and preprocess function is that the preprocess is called earlier and so is not limited to a single theme. Is it always the case that you could only use one or the other to achieve a theming task? Or do you sometimes have a choice of either?
Assuming you had a choice of using either, if the site only has 1 theme what is the benefits of either option?
Theme functions and preprocessors are different animals, and they each serve different purposes. Whether or not to use either or both of these components depends on what you're trying to accomplish, and they are not mutually exclusive. More info on how Drupal's presentation layer works can be found at https://www.drupal.org/node/933976 and http://themery.com/dgd7.
As you mentioned, preprocessors do run first. They are used to manipulate certain render arrays and set up all the variables that are to be passed on to the template or theme function. Some preprocessors might focus on menu links, others might focus on blocks, and yet others might focus on views. You could, for example, use a theme_preprocess_menu_link() function to remove a title element from a menu link if you did not want it to appear in the final output.
Theme functions are used to process a render array into HTML code. They serve the same purpose as template files, except that they do all their work in PHP code rather than reading in a .tpl.php file and merging it with the render array to produce HTML. Theme hooks and suggestions are used to tell Drupal how it is to override its default theme to render something, using either template files or theme functions.
This design lets Drupal assign as much of the processing and logic as possible to the preprocessors and theme hooks, so that the theme functions or templates can focus on producing nice, clean markup without having to contain too much code and logic. It also enables the output of properly-designed Drupal modules to be theme-agnostic, where the final look of that output can be adapted for any theme design.
Even if a site only has one theme, preprocessors, theme functions, theme hooks and templates are still quite useful as well as necessary for many purposes.
Preprocess functions are meant for setting up variables that will be sent to the theme function or theme file.
They are for different purposes so you should not be choosing between them.
Basically...
Preprocess function contain PHP, adding variables to the variables array.
Theme functions/files output HTML depending on the variables passed to it from the preprocess function.
When I clear my theme registry Drupal runs off and builds out a nice consolidated css file, but it does this for different node/page types so that I get several instances of said file existing. I mentioned this in another question I asked (and answered), but my question is, how does Drupal deduce what css files it needs to add to the consolidated version? There must be numerous different places that control what modules appear on a particular node, so what constitutes a rule for another css file being built?
Well that wasn't an easy chain of functions to follow but I think I've got there...
Every time a page is 'refreshed' (i.e. built from scratch, not served from cache) all CSS files added with drupal_add_css() during that page build are aggregated and saved to a single file that is returned as the <link> tag for that page.
The following line in drupal_add_css() decides what the aggregated CSS file's name will be:
$filename = 'css_'. md5(serialize($types) . $query_string) .'.css';
$types in this context is an array of all of the CSS files added using drupal_add_css() during the current page build. The filename for the aggregated CSS contains a serialised string of $types, which essentially means that any other page that adds the same CSS files as that one will receive exactly the same file name and thus load the same CSS file.
So basically, the aggregation function is run for every single page build so all CSS added to that page will be aggregated every time. If certain pages happen to use the same modules then they will automatically be served the same CSS file as defined in the PHP snippet above. When you combine that with page caching you get the results you find in the HTML source on the different pages.
Hope that makes sense!
I want to edit the search results of a search using the search module. The template in question is search-result.tpl.php. I see that it's in html/modules/search, but I'd like to keep the modification out of the core and keep it in my sites folder. Is there a way to change the place that drupal looks for that specific template? If not, how can I accomplish my goal?
Copy the search-result.tpl.php into your theme's directory, modify it as needed, and clear the theme cache.
You may also want to check out the About overriding themable output handbook page for additional details.
I have been using a custom template file called user-profile.tpl.php for a while. But wanted to explore the CCK Content Profile abilities.
I renamed the template file to something arbitrary, but instead of drupal defaulting to using the standard profile view it is complaining that it can't find the user-profile.tpl.php file.
So either it saves this in the database somewhere, cache is disabled so that is not the Anyone know how drupal save the template file names? And how that can be reset?
Make sure you flush the theme registry whenever you make a change like that. You can do it using the link in the top left of admin_menu if you're using that module, or if not, go to Settings -> Performance and clear the cache.