Welcome to the sixth settlement of our tutorial series on how to build your own Multilingual MVC CMS from scratch and in which I will get into full detail as to how themes and languages are managed in our project.
During the last settlement, I have demonstrated a way of building a user interface that allows us to register, sign in and review/update personal data. I have also challenged you, aided by all the knowledge you have gained so far, to try and build some additional features like forgotten password, password changing and extra settings modules on your own project, operation that you should not be so difficult by now and that should considerably enhance the interface you have started to build, if you have.
But today, I will be getting in a totally different aspect of the project, gathering all the previously discussed elements about theme and language handling and coming full circle by giving you a complete, synthesized overview of the matter. I will point out however, that this will not have any direct relation with the back-end language and theme management features we will be starting to create during the next settlements, as this will in fact only be a discussion about everything pertaining to theme/language handling, mostly in front end.
So, starting with languages and starting with the obvious, all language files, whether used in back-end or in front-end, will fall under the same directory structure as shown right bellow
The file named encoding.php merely holds an array containing charsets on a per language basis, we will later review the method it is being useful to.
The file named translate.js contains a script that's needed to help localize all Javascript strings. Since I have already presented it in a previous article (http://www.sitepoint.com/localizing-javascript-strings-php-mvc-framework/), I will not need to do so here.
Obvious is the fact that each language folder contains its own flag, in .png format.
One thing that differentiates the front-end section however, is that a template folder has been added to address template needs while sending out emails, eg: confirmation of registration, contact form and new password sending. Indeed, a user who has registered using Swedish may not like to receive a confirmation all written in English or in any language other than Swedish for that matter.
Let's now take the example of registration_en.php
Interesting too is the constant named CONTACT_FORM_RECEIVER_LANGUAGE, which is used to define the language in which the administrator will like to receive its feedback emails.
And now, time to get into the controversial debate about global variables. Since day 1, I have chosen to use global variables to access the translation strings we have just discussed. So, for example, throughout the whole site, we may access $t_welcome by using $GLOBALS['t_welcome'], which turns out to be greatly convenient, for a number of reasons.
Although... I can hear some of you screaming 'globals? DO NOT USE GLOBALS!', which is sometimes fair in its own right. But passed the fact that I myself am totally not convinced using globals for my translation system here will affect the project or anyone instantiating/using it, fact is, I have even yet to be convinced by the generally advised methods in the field, which are either about stacking everything into array from which translations are latter picked, or using POEdit/gettext which I don't feel truly answers the specific needs I have been having for this project so far.
So that, the array method being pretty cumbersome to maintain and great only for small localization projects and also, with over 1000 translation strings for each language, unless someone comes up with a great new way to handle localization that's easily and quickly implementable, even in large-scale environments, that's the method I will keep using. Besides, not only this is the one method I am myself being the most comfortable with, this is also a method that neither ever failed me nor made waves somewhere else in the project since I have started implementing it. So, as programmers too sometimes say: 'Don't repair it if it ain't broken!'.
But the truth is, within our project, there is much more to language handling than mere string localization.
Let's start from the localization table and then go on with the language selector bar
And from this table, we can start building a language selector bar users will be able to interact with, shifting from one language to another easily.
At the beginning of these series, I have presented the template engine that dynamically includes all the necessary view files, plus takes care off the passing of variables from the controller. But there's of course more to theme handling than this powerful routine. I justify:
Let's start by analyzing the overall structure of the theme folder
Then the same structure in more detail
From this picture above, you can see there are two different styles being operated, which are named skane and sparta. These folders exist in the back-end section too but vary in content.
At root (/themes/your_style), you can find all the view files proper to each module and not only. There lie our common template files header.php, main.php and footer.php and we can also find secondary view files like vf_image_u.php or follow.php, which respectively create an image for the captcha in registration.php and create a social media follow bar to be included wherever found stylish inside main.php. More interesting view files can be found there, like paging.php but we will get to them during the forthcoming settlements only.
Jumping straight into the css folder, we find name_of_the_style.css.php which is the main css file for any given theme. It bares a .php extension because on some occasions we need to use PHP variables there. We also find specific CSS files for the libraries we use like dTree, which has dtree.css sitting there and so on.
On the same level as the css folder, we find a folder called images. That folder holds two sub-folders called favicon and servicing. While it looks obvious what the favicon folder is here for, the servicing folder however requires a little explanation. It is a folder that holds images that will not only build on the visual identity of a given theme, but that are also dedicated to common navigation items. As an example, servicing is the folder where you will find small arrows, warning and missing page/module icons. And since menus are considered standard navigation items, you will also find two sub-folders called dtree and hmenu, which contain images for use with the menu system you already know of. In fact a third sub-folder to the servicing folder can even be found, called rss, which contains a few rss feed logo .png format images to choose from (see RSS_ICON_FILE in config.php).
At the root level of /themes/your_style/images, therefore at the same level where the favicon and servicing folder are, can main logo images be found.
Entering the /themes/your_style/css folder again, we find there's an image folder too, not to be confused with /themes/your_style/images. This will contain images for use in Javascript dialog boxes. Note these dialog boxes are also configurable via /themes/your_style/css/dialog_box.css.
Back at the root level of the themes folder reside two of our common template files. The first one is header.php
A note about meta tags though, please visit https://support.google.com/webmasters/answer/79812?hl=en for a brief overview of the tags Google Inc. understands.
Then we go onto including all needed CSS/Javascript files and end up using a noscript tag that will warn users in case Javascript is disabled on their viewing device. That's all there is to the header file found in the front-end. In a next settlement though, we will see the header file for the back-end contains a lot more information, primarily due to TinyMCE being initialized there. Note that header.php ends with the closing head tag.
Meanwhile, in footer.php, the starting tag is a tr tag and the closing tag is the closing html tag
But next time, I will take these series to yet another level, getting onto the other side of the fence by introducing you to the back-end side of our CMS, starting with the building of a really exciting language management module. Creating this new module will allow me, among other things, to tell you more about the paging and sorting features many of the back-end modules actually depend on.
This article first appeared Thursday the 16th of February 2016 on RolandC.net.
During the last settlement, I have demonstrated a way of building a user interface that allows us to register, sign in and review/update personal data. I have also challenged you, aided by all the knowledge you have gained so far, to try and build some additional features like forgotten password, password changing and extra settings modules on your own project, operation that you should not be so difficult by now and that should considerably enhance the interface you have started to build, if you have.
But today, I will be getting in a totally different aspect of the project, gathering all the previously discussed elements about theme and language handling and coming full circle by giving you a complete, synthesized overview of the matter. I will point out however, that this will not have any direct relation with the back-end language and theme management features we will be starting to create during the next settlements, as this will in fact only be a discussion about everything pertaining to theme/language handling, mostly in front end.
Language handling
So, starting with languages and starting with the obvious, all language files, whether used in back-end or in front-end, will fall under the same directory structure as shown right bellow
The file named encoding.php merely holds an array containing charsets on a per language basis, we will later review the method it is being useful to.
<?php
/* languages/encoding.php */
$encod = array(
'en' => 'utf-8',
'fr' => 'utf-8',
'uk' => 'utf-8',
'ru' => 'utf-8',
'de' => 'utf-8',
'nl' => 'utf-8',
'se' => 'utf-8',
'es' => 'utf-8'
);
?>
The file named translate.js contains a script that's needed to help localize all Javascript strings. Since I have already presented it in a previous article (http://www.sitepoint.com/localizing-javascript-strings-php-mvc-framework/), I will not need to do so here.
Obvious is the fact that each language folder contains its own flag, in .png format.
One thing that differentiates the front-end section however, is that a template folder has been added to address template needs while sending out emails, eg: confirmation of registration, contact form and new password sending. Indeed, a user who has registered using Swedish may not like to receive a confirmation all written in English or in any language other than Swedish for that matter.
Let's now take the example of registration_en.php
<?php
/* languages/templates/en/registration_en.php */
$content = "
<html>
<head>
<title>Your registration</title>
</head>
<body>
<p>Thank you for your registration on \"".SITE_TITLE."\"!</p>
Your credentials are
<table>
<tr>
<td>Login : </td>
<th>".$login."</th>
</tr>
<tr>
<td>Pass : </td>
<th>".$password."</th>
</tr>
</table>
<p>
Regards,<br />
the site's team
</body>
</html>
";
?>
Interesting too is the constant named CONTACT_FORM_RECEIVER_LANGUAGE, which is used to define the language in which the administrator will like to receive its feedback emails.
define("CONTACT_FORM_RECEIVER_LANGUAGE","en"); // the code of the language in which you wish to receive the user contact messages
<?php
/* from languages/en/en.php */
$t_welcome = 'Welcome';
$t_contact = 'Contact';
$t_registration = 'Register';
$t_reg = 'Register';
$t_copyright = 'Copyright';
$t_submit = 'Submit';
$t_save = 'Save';
...
?>
And now, time to get into the controversial debate about global variables. Since day 1, I have chosen to use global variables to access the translation strings we have just discussed. So, for example, throughout the whole site, we may access $t_welcome by using $GLOBALS['t_welcome'], which turns out to be greatly convenient, for a number of reasons.
Although... I can hear some of you screaming 'globals? DO NOT USE GLOBALS!', which is sometimes fair in its own right. But passed the fact that I myself am totally not convinced using globals for my translation system here will affect the project or anyone instantiating/using it, fact is, I have even yet to be convinced by the generally advised methods in the field, which are either about stacking everything into array from which translations are latter picked, or using POEdit/gettext which I don't feel truly answers the specific needs I have been having for this project so far.
So that, the array method being pretty cumbersome to maintain and great only for small localization projects and also, with over 1000 translation strings for each language, unless someone comes up with a great new way to handle localization that's easily and quickly implementable, even in large-scale environments, that's the method I will keep using. Besides, not only this is the one method I am myself being the most comfortable with, this is also a method that neither ever failed me nor made waves somewhere else in the project since I have started implementing it. So, as programmers too sometimes say: 'Don't repair it if it ain't broken!'.
But the truth is, within our project, there is much more to language handling than mere string localization.
Let's start from the localization table and then go on with the language selector bar
<?php
--
-- Table structure for table `localization`
--
CREATE TABLE `localization` (
`id_localization` smallint(6) NOT NULL,
`localization_name` varchar(3) NOT NULL,
`localization_flag` varchar(8) NOT NULL,
`localization_enabled` enum('no','yes') NOT NULL,
`localization_default` enum('no','yes') NOT NULL,
`localization_timestamp` timestamp NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Dumping data for table `localization`
--
INSERT INTO `localization` (`id_localization`, `localization_name`, `localization_flag`, `localization_enabled`, `localization_default`, `localization_timestamp`) VALUES
(7, 'se', 'se.png', 'no', 'no', '2014-10-24 19:17:26'),
(8, 'es', 'es.png', 'no', 'no', '2014-10-24 19:17:26'),
(5, 'ru', 'ru.png', 'no', 'no', '2014-10-24 19:17:26'),
(6, 'nl', 'nl.png', 'no', 'no', '2014-10-24 19:17:26'),
(3, 'fr', 'fr.png', 'yes', 'yes', '2014-10-24 19:17:26'),
(4, 'uk', 'uk.png', 'no', 'no', '2014-10-24 19:17:26'),
(1, 'en', 'en.png', 'yes', 'no', '2014-10-24 19:17:26'),
(2, 'de', 'de.png', 'no', 'no', '2014-10-24 19:17:26'),
(10, 'dk', 'dk.png', 'no', 'no', '2014-10-24 19:17:26');
--
-- Indexes for dumped tables
--
--
-- Indexes for table `localization`
--
ALTER TABLE `localization`
ADD PRIMARY KEY (`id_localization`);
--
-- AUTO_INCREMENT for dumped tables
--
--
-- AUTO_INCREMENT for table `localization`
--
ALTER TABLE `localization`
MODIFY `id_localization` smallint(6) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=11;
?>
And from this table, we can start building a language selector bar users will be able to interact with, shifting from one language to another easily.
<?php
/* from themes/your_style/main.php */
// we fetch an instance of the localization model
// and call the method that will retrieve all enabled languages
$lang_bar = LocModel::getInstance()->getData_language_bar();
foreach($lang_bar as $ln_item){//for each language
if(GRAPHICAL_LN_BAR == true){
// if flag view is set, we display the flag for each language
// wrapped in the target url
// The get_ln_straight() method from bellow
// will take in a URL and process it to match the language
// on which the mouse is hovering,
// all while preserving the other elements the current URL contains, as well as their order
?>
<a href="<?php echo LocModel::getInstance()->get_ln_straight($ln_item[0]); ?>"><img src="<?php echo CLEAN_PATH.'/'; ?>languages/<?php echo $ln_item[0]; ?>/<?php echo $ln_item[1]; ?>" width="<?php echo FLAG_WIDTH; ?>" height="<?php echo FLAG_HEIGHT; ?>" alt="<?php echo isset($GLOBALS['t_'.$ln_item[0].'_lng'])?$GLOBALS['t_'.$ln_item[0].'_lng']:"$ln_item[0]"; ?>" /></a> <?php
}
else{
?>
<a href="<?php echo LocModel::getInstance()->get_ln_straight($ln_item[0]); ?>"><u><?php echo $ln_item[0]; ?></u></a> <?php
}
}
}
?>
<?php
/* from application/models/LocModel.php */
...
public function getData_language_bar(){
$this->locData = array();
$line = array();
// we first check what language directories (inside both front-end and back-end /language dirs)
//exist physically on server. We use PHP's glob() function for that
$language_directories = glob(PATH_TO_LANGUAGES . '/*' , GLOB_ONLYDIR);
$language_admin_directories = glob('admin/'.PATH_TO_LANGUAGES. '/*' , GLOB_ONLYDIR);
$admin_language_list = array();
foreach($language_admin_directories as $admin_dir){
$exp_admin_dir = explode("/",$admin_dir);
array_push($admin_language_list, end($exp_admin_dir));
}
$language_list = array();
foreach($language_directories as $dir){
$exp_dir = explode("/",$dir);
// if the currently processed front-end language dir can be found in the admin language dir array,
// we push it inside the $language_list array, to be used later for checking
if( in_array( end($exp_dir), $admin_language_list)){array_push($language_list, end($exp_dir));}
}
//then we pull out the language list from the db
$q_ln_bar = "SELECT id_localization, localization_name, localization_flag, localization_enabled
FROM localization
WHERE localization_enabled = 'yes'
ORDER BY id_localization ASC
";
MySQLModel::get_mysql_instance()->executeQuery($q_ln_bar);
while($mylnbar = MySQLModel::get_mysql_instance()->getRows($q_ln_bar)){
//we now compare the each freshly pulled language row from the DB
//with our array of check existing physical language dirs
if(in_array($mylnbar['localization_name'], $language_list)){
// so that, basically, if the name of the currently processed language corresponds to existing language folders
//in both back-end and front-end at the same time, we consider that language valid and stack it in an array,
//that will be stacked with other arrays in one more array that will be returned to us as a whole
array_push($line, $mylnbar['localization_name'],$mylnbar['localization_flag']);
array_push($this->locData,$line);$line = array();
}
}
return $this->locData;
}
...
?>
<?php
/* from application/models/LocModel.php */
...
public function get_ln_straight($lang){
//using $_SERVER['QUERY_STRING'] will make our life a lot easier when it comes to dealing with clean URLs
if(empty($_SERVER['QUERY_STRING'])){ // if $_SERVER['QUERY_STRING'] turns out empty we use default values
if(DEFAULT_PLINK){$plink = '&'.PLINK.'='.CURRENT_PLINK;} else{$plink = '';}
$_SERVER['QUERY_STRING'] = RLINK.'='.CURRENT_RLINK.$plink.'&'.LN.'='.CURRENT_LANG;
}
$this->query_string = $_SERVER['QUERY_STRING'];
$pat = '/'.LN.'=[a-z]{2}/';
$pat2 = '/language=[a-z]{2}/'; //that's for Google CSE
//if we can spot a valid URL language atom, we replace it by the then-sought language, $lang,
//initially passed as parameter to the method
if(preg_match($pat, $this->query_string, $matches, PREG_OFFSET_CAPTURE, 3)){
$rpl = LN.'='.$lang;
$this->query_string = preg_replace($pat, $rpl, $this->query_string);
}
if(preg_match($pat2, $this->query_string, $matches, PREG_OFFSET_CAPTURE, 3)){
$rpl2 = 'language='.$lang;
$this->query_string = preg_replace($pat2, $rpl2, $this->query_string);
}
//normally at that point, we should already be fine,
//but clean urls come complicating everything again...
if(CLEAN_URLS == true){//if clean urls are on,
//we don't just preg_replace our query string, we explode it.
$exp_query_string = explode('&', $this->query_string);
$markers = array(
//and here come markers
//basically, markers are something we use with clean_urls whenever thought necessary,
//to avoid collision between .htaccess rewrite rules, when there are (too) many of them
'pn' => PGN,
//note that 'pn' is what will be written in .htaccess
//and PGN is the constant name that normally holds the page number url variable 'pgn'.
// again, with clean urls being off, you could assign any other value than pgn to the constant PGN
'sn' => SN
);
$fake_string = array(); //this will hold our new url string until imploded
foreach($exp_query_string as $atom){ //for each atom of the old string (x=y)
$exp_atom = explode("=",$atom); // we explode it (the atom)
$needle = $exp_atom[0]; //and take its left part, called the needle in this case
if(!preg_match('/success/',$atom)){// we avoid the word success in our algorithm for collision reasons
//we then search for that needle inside the haystack (marker's array)
if(in_array($needle, $markers) ){
//if found, we will create a new clean atom with the marker in it.
//because that's what markers are here for - making clear what the nature of the value they bare is
$key = array_search($needle, $markers); //so we get its key
$new_atom = $key.'/'.$exp_atom[1]; //and actually create the new 'clean' atom using that key,
//a slash sign and the value of the old one
}
else{$new_atom = $exp_atom[1];} // otherwise, if the atom does not need a marker, we retain only the x part of the old string
array_push($fake_string,$new_atom); //and we stack each resulting atom in our $fake_string array
}
}
///and then we turn that array to a string, using '/' to implode all parts
$new_string = implode("/", $fake_string);
//we quickly append our clean path constant and we're good to go
$this->query_string = CLEAN_PATH.'/'.$new_string;
//not just yet though... in case of Google CSE
if(preg_match('/cx=(.*)&gs=(.*)&sa.x=(.*)&sa.y=(.*)/', $_SERVER['REQUEST_URI'])){
// so, if google search is on
//we explode not the query string but the request URI this time
$exp_q_s = explode('?',$_SERVER['REQUEST_URI']);
$this->query_string .= '?'.$exp_q_s[1]; //and retain only the parts proper to Google,
//(so the user keeps seeing its search results after it has selected another language),
//we concatenate them to the query string we've just built and now we're good to go.
}
}
else{
//else, if clean urls weren't set, we only need to append $_SERVER['PHP_SELF']
//instead of the clean path constant before the new string we have built
$this->query_string = $_SERVER['PHP_SELF'].'?'.$this->query_string;
}
return $this->query_string; //we return our resulting string
}
?>
<?php
/* from application/models/LocModel.php */
...
public function get_encoding_straight($lang){
require PATH_TO_LANGUAGES.'/encoding.php'; // we require the file that contains the $encod array, as discussed earlier today.
if (array_key_exists($lang,$encod)){ //if we can find the current language in that array, as key
$this->encoding = $encod[$lang]; we then use its corresponding value
}
else{$this->encoding = 'utf-8';} //else we default to utf-8
return $this->encoding; //we return what we have then
}
?>
Theme handling
At the beginning of these series, I have presented the template engine that dynamically includes all the necessary view files, plus takes care off the passing of variables from the controller. But there's of course more to theme handling than this powerful routine. I justify:
Let's start by analyzing the overall structure of the theme folder
Then the same structure in more detail
From this picture above, you can see there are two different styles being operated, which are named skane and sparta. These folders exist in the back-end section too but vary in content.
At root (/themes/your_style), you can find all the view files proper to each module and not only. There lie our common template files header.php, main.php and footer.php and we can also find secondary view files like vf_image_u.php or follow.php, which respectively create an image for the captcha in registration.php and create a social media follow bar to be included wherever found stylish inside main.php. More interesting view files can be found there, like paging.php but we will get to them during the forthcoming settlements only.
Jumping straight into the css folder, we find name_of_the_style.css.php which is the main css file for any given theme. It bares a .php extension because on some occasions we need to use PHP variables there. We also find specific CSS files for the libraries we use like dTree, which has dtree.css sitting there and so on.
On the same level as the css folder, we find a folder called images. That folder holds two sub-folders called favicon and servicing. While it looks obvious what the favicon folder is here for, the servicing folder however requires a little explanation. It is a folder that holds images that will not only build on the visual identity of a given theme, but that are also dedicated to common navigation items. As an example, servicing is the folder where you will find small arrows, warning and missing page/module icons. And since menus are considered standard navigation items, you will also find two sub-folders called dtree and hmenu, which contain images for use with the menu system you already know of. In fact a third sub-folder to the servicing folder can even be found, called rss, which contains a few rss feed logo .png format images to choose from (see RSS_ICON_FILE in config.php).
At the root level of /themes/your_style/images, therefore at the same level where the favicon and servicing folder are, can main logo images be found.
Entering the /themes/your_style/css folder again, we find there's an image folder too, not to be confused with /themes/your_style/images. This will contain images for use in Javascript dialog boxes. Note these dialog boxes are also configurable via /themes/your_style/css/dialog_box.css.
Back at the root level of the themes folder reside two of our common template files. The first one is header.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<?php
// here we sort out language code names to be compatible with most standards
if(CURRENT_LANG){
if(CURRENT_LANG == 'uk'){$tinymce_lang = 'uk_UA';}
elseif(CURRENT_LANG == 'fr'){$tinymce_lang = 'fr_FR';}
elseif(CURRENT_LANG == 'se'){$tinymce_lang = 'sv_SE';}
else{$tinymce_lang = CURRENT_LANG;}
}
else{$tinymce_lang = 'en';} // if nothing was found, we default to English
?>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?php echo $tinymce_lang; ?>" lang="<?php echo $tinymce_lang; ?>">
<head>
<?php
$header_utils = new UtilsModel();
$met = $header_utils->get_meta_info(); //we fetch meta infos from the DB, this is being discussed further down the page.
foreach($met as $m){ //for each meta entry...
if($m[0] == 'title'){ // if tag is title
echo '<title> ';
if(isset($page_name)){echo $page_name;}
else{
if(isset($module_name)){
echo isset($GLOBALS['t_'.strtolower($module_name)]) ? $GLOBALS['t_'.strtolower($module_name)] : $module_name;
}
}
echo '</title>';
}
else{ //if not title tag, we use the rest of what we have pulled from the meta table.
if($m[0] == 'http-equiv'){
if($m[1] == "Content_Type"){$m[1] = "Content-Type";}
$char = " charset = ".LocModel::getInstance()->get_encoding_straight(CURRENT_LANG)."";
$m[2] .= $char;
}
echo '<meta '.$m[0].'="'.$m[1].'" content="'.$m[2].'" />';
}
}
?>
<!-- now we link all the CSS/JS we need on our project -->
<link rel="shortcut icon" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/images/favicon/favicon.ico" type="image/x-icon" />
<link rel="stylesheet" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/css/<?php echo CURRENT_THEME; ?>.css.php" type="text/css" />
<link rel="stylesheet" type="text/css" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/css/dtree.css" />
<link rel="stylesheet" type="text/css" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/css/hmenu.css" />
<link rel="stylesheet" type="text/css" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/css/dialog_box.css" />
<link rel="stylesheet" type="text/css" href="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES; ?>/<?php echo CURRENT_THEME; ?>/css/dtp.css" />
<script src="<?php echo CLEAN_PATH.'/'; ?>languages/<?php echo CURRENT_LANG; ?>/JS/<?php echo CURRENT_LANG; ?>.js" type="text/javascript"></script>
<script src="<?php echo CLEAN_PATH.'/'; ?>languages/translate.js" type="text/javascript"></script>
<?php
include 'public/js/main.php';
include 'public/js/dtree.php';
?>
<script src="<?php echo CLEAN_PATH.'/'; ?>/public/js/hmenu.js" type="text/javascript"></script>
<?php include 'public/js/dialog_box.php'; ?>
<script src="<?php echo CLEAN_PATH.'/'; ?>public/js/dtp.js"type="text/javascript"></script>
<!-- and in case Javascript is disabled, we use a noscript tag -->
<noscript><div class="disabled_feature"><?php echo $GLOBALS['t_javascript_has_been_disabled']; ?> <?php echo $GLOBALS['t_please_reenable_it']; ?> - <a href="http://www.enable-javascript.com" target="_blank"><u><?php echo $GLOBALS['t_instructions_here']; ?></u></a></div>
</noscript>
</head>
--
-- Table structure for table `meta`
--
CREATE TABLE `meta` (
`id_meta` tinyint(4) NOT NULL,
`meta_type` varchar(12) NOT NULL,
`meta_name` varchar(40) NOT NULL,
`meta_value` text NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
--
-- Dumping data for table `meta`
--
INSERT INTO `meta` (`id_meta`, `meta_type`, `meta_name`, `meta_value`) VALUES
(1, 'title', 'title', 'Gumbo-CMS'),
(2, 'name', 'description', 'Gumbo (or Gumbo-CMS) is a Mutilingual MVC CMS written \'from scratch\' in PHP 5 and that requires Apache 2.2+ and MySQL 5.6+'),
(3, 'name', 'keywords', 'cms, mvc, php, multilingual cms'),
(4, 'name', 'robots', 'index, follow'),
(5, 'name', 'google_bot', 'index, follow'),
(6, 'name', 'google', 'notranslation'),
(7, 'http-equiv', 'Content_Type', 'text/html;');
--
-- Indexes for dumped tables
--
--
-- Indexes for table `meta`
--
ALTER TABLE `meta`
ADD PRIMARY KEY (`id_meta`);
--
-- AUTO_INCREMENT for dumped tables
--
--
-- AUTO_INCREMENT for table `meta`
--
ALTER TABLE `meta`
MODIFY `id_meta` tinyint(4) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=8;
A note about meta tags though, please visit https://support.google.com/webmasters/answer/79812?hl=en for a brief overview of the tags Google Inc. understands.
Then we go onto including all needed CSS/Javascript files and end up using a noscript tag that will warn users in case Javascript is disabled on their viewing device. That's all there is to the header file found in the front-end. In a next settlement though, we will see the header file for the back-end contains a lot more information, primarily due to TinyMCE being initialized there. Note that header.php ends with the closing head tag.
Meanwhile, in footer.php, the starting tag is a tr tag and the closing tag is the closing html tag
<?php
/* themes/your_style/footer.php */
?>
<tr class="footer_tr">
<td colspan="2" class="footer">
<?php echo $GLOBALS['t_copyright'].' '.COPYRIGHT; ?>
</td>
</tr>
</table>
</div>
</body>
</html>
But next time, I will take these series to yet another level, getting onto the other side of the fence by introducing you to the back-end side of our CMS, starting with the building of a really exciting language management module. Creating this new module will allow me, among other things, to tell you more about the paging and sorting features many of the back-end modules actually depend on.
This article first appeared Thursday the 16th of February 2016 on RolandC.net.
