php files inclusion structure in Joomla? - php

I am currently experimenting with Joomla (3.7) templating system for my company. I am not new in php and inclusion, but a beginner with Joomla.
I have been searching through the web and i haven't found any clear structure schema for the file inclusion in Joomla, something like what we can find here for wordpress for example: https://codex.wordpress.org/File:Template_Hierarchy_2015.png
For example, i stumbled upon this: while experimenting with template creation, i wanted to store a value that could be used in a layout, testing setUserState function. The layout i tested was the one used to render custom fields (which are new in 3.7). The result is that it seems that fields/render.php is actually executed before template's index.php (the value is only available after page reload when set in index.php, whereas it is immediate when set in render.php).
Did someone saw a clear schema of this inclusion structure? It is not only for the said example, but mostly for a better understanding of the framework.. sorry if already asken or if too vague for the site.
edit - note about my example: collecting info bits by bits, it seems that the template file index.php is executed first and buffered so that it can be parsed for jdoc statements. Intuitively, because an article content is in this case imported by a jdoc (<jdoc:include type="component" />, the main content in the article page), the custom fields render.php should be called after index.php. Could it be the buffering part that prevents the user state to be set in time?

Related

Datalife engine - where are the functions in .tpl files called from?

I'm migrating my blog from wordpress to datalife engine. For what i figured it out by searching, is writen in smarty php... I never worked with it before and i want to query the database to implement something on the theme... But i can't write it on the tpl files...
What i want to know is, where are functions like {rating}, {content} or [related-news] declared...
i want to query the database, but for what i know, i can't do it on the tpl files direcly.
And i can't find any info where they are because all the readme files of datalife are in russian. Can someone help me to figure out how is this structure done?
Datalife Engine use the module files in folder /engine/modules/ to define which .tpl files to use for which function, so there is no single file that declare all tpl files, you have to check which module or which function you want to edit, in your case it seems like you are looking for full page of content which in DLE called "fullstory" the module that handle this module is engine/modules/show.full.php and the theme file to use for this module are fullstory.tpl to dispaly the rest of fullstory, addcomment.tpl for add comment form and relatednews.tpl to display related news, about {rating} there are at least 3 modules use this tag which are show.short.php, show.custom.php and show.full.php, however the DLE structure is each module use its own tpl file to display as {content}, I think if you go to dlestarter.com you can get all answer you need from them, I think they are not so advanced team but they do speak English so they can help you more effectively to any questions you may have...good luck!
Datalife Engine does not use smarty template engine!.
It has it's on custom engine.
The Flow of the cms its simple, every article has a short story and optionally a full story.
In the template folder you have a bunch of tpl files with build up the final page.
main.tpl beeing the file called for every page you display.
Now typically once you call the front page the main.tpl along with shortstory.tpl are called along with other blocks for the front page.
the shortstory.tpl is build by the /engine/modules/show.short.php file witch will call the db for the data or memcached if enabled and the data was cached replace the the engin tags with the necessary data like {title} and many others.
You should really look at the documentation to undestand witch tags are found in witch section.
One important think to note is that you cannot add php in the tpl files at least not out of the box but you can include files with php in them.
I recommend heading over to dlestarter.com they are a good reference for documentation in English and pretty much the only once as well. They also have a forum where i look into sometimes.

how Joomla back-end's core works?

In the Joomla back-end, the administrator would do modifications using the GUI.
Say a module is enabled(just click the check box).
What happens in php-level?(what happens to the code?)
Some trivial assumptions I come up with are,
-commenting/uncommenting
-some code snippets are added/removed
-configuration(ex: xml) files are modified/created
Joomla itself doesn't really modify files on disk much at all. The only exceptions I can think of are:
Installing an extension (writes to '/tmp', and then the final location for the extension files)
Saving global configuration options (writes to '/configuration.php')
Caching (writes to '/cache')
All other configuration changes, entered data, etc from the admin area (and frontend) are stored in the Joomla database.
So the example given (enabling/disabling a module) doesn't edit or create any files. It only makes changes in a core database table (jos_modules, if your DB prefix is 'jos_'). Module inclusion on all pages is dynamically evaluated per page-load based on the code in your template, as #Hanny mentions.
If you read the index.php file in of the template you're using - you'll find that all the positions of the template are included in that file <jdoc include="position10" /> or something of that nature is what it will say.
Usually the templates use CSS to help determine how to 'shape' the page depending on which modules are enabled, along with 'if,then,else' statements on the php level. Read through the index.php file and you'll probably see that.
if "module10" then use "rightmodule.css" type thing - which then may hold changes to be made to certain containing div's with regards to width and that sort of thing.
No commenting/uncommenting happens, no code snippets are added and no configuration files are modified/created (at least as far as I know, and I've worked to design a component for Joomla previously). It's all if statements and tying that together with the module positions that are laid out in the templates index.php file.
This is a simplified answer, but I think it answers what you've asked.

CMS permalink and templating system how to?

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. ;]

How Does Drupal 7 Render Out a Page?

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.

How should I integrate some javascript into a php application?

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.

Categories