RolandC.net

So, how do you get fully accepted into Adsense these days? (August 2016)

noreply@blogger.com (rolandc.net) — Thu, 04 Aug 2016 14:17:00 +0000

Lots of people keep making videos about how you have to do this and target that so that maybe one day the Adsense people will take you in and that if you never get fully enrolled then guess what there are other ad programs out there so that Google ain't the best thing on earth afterall and so on and so on... STOP

I thought I'd write a little article that will save you some time and frustration, hopefully lightening your path a little. That supposes of course that you have applied at least twice to get full acceptance into the program and that currently you're in a state of almost wanting to bang your head against the wall because you can't figure out what it takes to get Adsense and that it makes you feel psychotic every time you start thinking about it.

Fine, but RolandC.net, what do I need to do to get fully accepted into the Adsense program?

The answer is both simple and short: BE TRULY USEFUL to someone (not just to yourself).

Let me clarify what I just wrote. I did not even have 18 (probably 17 or 16) articles when I applied (and got full acceptance), so don't even listen to those who recommend having at least 20-25 quality articles.

And frankly, quality is not even the point here. Google does not need quality, it needs usefulness, hear problem solving, creating solutions.

Before I elaborate on this, a little word about traffic, as not only I remember having had less than 18 posts for sure, I was also averaging the 30 visits a day or so, probably even less at that time. Felt lonely on my Blogger platform...well who cares, I did get accepted anyway

Of course, your content should reflect the fact that you've benefited from some sort of, quote on quote, education somewhere along the way, and your website/blog's visual identity should convey your own personal spirit or your product/services's spirit or whatever, but that's not to the point, the point being that your content should solve problems, bring solutions (and not just to you but to people that are actually real and that actually need your content, so that the reader went 'Oh, gee! thanks so much for your article, it really saved my day!' or 'Gosh, I didn't know that! I'm so happy I found your blog!' or even 'Wow, this is so interesting, I gotta try that on my own too!'.

Bang! there you have it, if you can help people, if you can really be useful to anyone on this planet, then you will attract people (potential customers) and then advertisers want to know about you - here's your Adsense ID coming up right now! (well actually they first give you a link to download the Adsense app :))

Anyway, I'm not going to mention anything about the 'you have to be passionate' thing because it's obvious or it should obvious that if you write articles about something you know enough to help the community, that means you love what you do enough to be doing it, right? So if you have started creating content just to get Adsense, hoping you'll only have to sit on it afterwards waiting for Paypal® to come thru while sipping your beverage of choice on some sand beach somewhere, then this article wasn't for you to read, sorry.

Think about it this way, as an advertiser, would you invest money in people who don't have nothing helpful to tell (hear sell)? Would you invest your hard-earned money in people who only keep sharing things they haven't even created themselves? Would you invest in people who're only looking to get an income from advertising while not even trying to understand what advertisers need from them? (advertisers - those are the people who will pay you money in the end) and would you invest in people that....I forgot, sorry.

Anyway I hope you've enjoyed reading this article, that it'll help you either getting Adsense quick and easy at last (though truthfully), or find something else (better) to do with your life (you might wanna try the DMOZ directory project to get ideas if you don't have any - link opens in a new window and they have a brand new mascot there, green mascot actually).

Thank you for reading and don't forget to like&share&subscribe to rss and you know...

Stay tuned for more on RolandC.net!

This article first appeared Thursday the 4th of August 2016 on RolandC.net.

Can't access your Hotmail pop email anymore? (24th June 2016)

noreply@blogger.com (rolandc.net) — Fri, 24 Jun 2016 06:07:00 +0000

Yesterday (23rd June 2016), I have spent all day noticing Thunderbird could not retrieve my Hotmail pop email anymore. The following dialog boxes were constantly shown

I had also noticed that Hotmail's Webmail interface got a new paint job that day, and somehow I knew this had to be connected.

Right, it was !

Even though I had been getting my Hotmail email from Thunderbird for years without encoutering a single issue, I just realized that the option to get Hotmail's pop email retrieved was now disabled by default!

So, here's what I found while visiting Hotmail's Webmail option page:

Nice paint job huh?!

Just click on Yes and you will get your Hotmail email again as usual. No complicated two-step verification process involved or anything. That's as simple as that.

By the way, in case you can't figure out where the dialog box above came from, read on:

- Visit hotmail.com or I guess outlook.live.com is a shorter way here
- Click on the Settings menu (as found below)

- Click on Options

Then click on Mail -> Accounts -> POP and IMAP

Once there, don't forget to hit Save (a little above) and you're done.

I hope this helped you save the day by getting your customers email back in your email client as usual. Stay tuned for more on RolandC.net

This article first appeared Thursday the 16th of February 2016 on RolandC.net.

How to build your own Multilingual PHP MVC CMS from scratch - Part 6 - Language/Theme Handling

noreply@blogger.com (rolandc.net) — Tue, 16 Feb 2016 07:35:00 +0000

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.

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>  
 ";  
 ?>

Knowing HTML, you can all imagine what the output is going to look like in your favorite email client program.

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

Now for the core language files that hold most of the PHP localized strings, let's take the example of en.php

 <?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';  
 ...  
 ?>

As an unspoken rule, localized PHP strings follow the format $t_my_word_or_sentence = 'My word or sentence'; Thus the variable name is always lowercase, each word separated by an underscore, and t_ is appended at the beginning of each term. HTML tags may be used inside the literal string part, constants too, but best is to avoid this whenever possible, for readability at least.

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;  
 ?>

Nothing too unexplainable about this one, although it's a good occasion to remind you the timestamp field is here only to help force MySQL perform an update of at least one row every time we perform an operation but the data hasn't changed.

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   
           }  
      }  
 }  
 ?>

There is not much to write about the commented above code, expect for the call to the get_ln_straight() method, which will, no matter what the current URL is, make sure the language that's being displayed in the target link matches the flag/language name on which the mouse of the user is hovering, all while preserving the other elements the current URL contains, as well as their order. But before that, let's consider the useful getData_language_bar() method

 <?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;   
      }       
      ...  
   
 ?>

And then the get_ln_straight() method we have started to discuss earlier, here to ensure the user will always fall back on its feet while changing the language from any page

 <?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  
      }  
 ?>

Then still from the localization model, the get_encoding_straight() method, which if passed the current language as parameter, will return the corresponding charset, as defined in languages/encoding.php. This method will be used in header.php, both in front-end and back-end. By the way, we will get to the header files today while getting in the subject of theme handling, so we will have a chance to see the get_encoding_straight() method in action there.

 <?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  
      }  
 ?>

Finally, a word about the choice of character sets though: while this may feel odd to some of you that I sometimes modify the MySQL charset to Latin1 before attempting a query, from the way the database tables for this project were originally set up (latin1_swedish_ci), plus using utf-8 as HTML charset on all pages, no encoding-related display issues have yet arisen while testing the system against languages such as French, Russian or even Swedish, this on both Windows/*nix platforms. In other words, why changing what already works? But still, if you somehow end up getting encoding issues that I myself do not get, just try other values to see what works for you, although, everyone should be just fine with the settings as they currently are, regardless of the (modern) browser it's being displayed in.

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>

So, in header.php, we first sort out our language code names, for enhanced compatibility with the most standards officially in use and we use the freshly defined code in our html xml declaration. Then we pull all meta info from the DB table called meta, that looks as follows

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

and we start looping the results we have successfully fetched.

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>

Nothing too difficult about this one as well, and that wraps up this settlement in which you have learned more about the way languages and themes are dealt with in this project, getting for now a complete overview, for at least the front-end part.

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.

How to build your own Multilingual PHP MVC CMS from scratch - Part 5 - Frontend (part 3): User Interface

noreply@blogger.com (rolandc.net) — Tue, 29 Dec 2015 10:10:00 +0000

Welcome to the fifth settlement of our tutorial series on how to build your own Multilingual MVC CMS from scratch and in which we will be building an interface for the user to sign in and update its personal data.

During the last settlements, we have created a page module that allows the user to display a specific page based on URL input and aided by some third-party scripts, we have also created a customizable menu display system that comes in two layout flavors, vertical and horizontal. In a future settlement, I will show you how to create the back-end feature that will allow you to completely edit the menus stored in the database.

But for now, we will set our interest onto building a user interface that will allow for signing into the system as well as updating personal data. Now, since in reality, the user’s experience on this project encompasses at least 6 whole modules, which are: registration, sign in, forgotten password, account, profile, settings, password changing, plus the use of authentication model as well and that we obviously cannot review all of them at once, we will only be reviewing some of them, which are the registration, signin and profile modules. And this will still be a lot, so I will be focusing only on the parts that are of interest. This makes sense since there is no point in explaining how a controller works over and over again.

Anyway, the table named ‘users’ represents the natural entry point through which we will start digging our user interface.

 --  
 -- Table structure for table `users`  
 --  
   
 CREATE TABLE `users` (  
  `id_user` int(11) NOT NULL,  
  `user_login` varchar(12) NOT NULL,  
  `user_password` text NOT NULL,  
  `user_email` varchar(72) NOT NULL,  
  `user_country` varchar(255) NOT NULL DEFAULT 'uk',  
  `user_gender` enum('else','female','male') NOT NULL,  
  `user_birthdate` varchar(100) NOT NULL,  
  `user_type` enum('0','1','2') NOT NULL,  
  `user_ip` varchar(16) NOT NULL,  
  `user_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP  
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;  
   
 --  
 -- Dumping data for table `users`  
 --  
   
 INSERT INTO `users` (`id_user`, `user_login`, `user_password`, `user_email`, `user_country`, `user_gender`, `user_birthdate`, `user_type`, `user_ip`, `user_timestamp`) VALUES  
 (1, 'test', 'c08ac56ae1145566f2ce54cbbea35fa3', 'test@mail.com', 'fidji', 'male', '08/02/1985', '1', '127.0.0.1', '2015-10-02 00:55:41');  
   
 --  
 -- Indexes for dumped tables  
 --  
   
 --  
 -- Indexes for table `users`  
 --  
 ALTER TABLE `users`  
  ADD PRIMARY KEY (`id_user`);  
   
 --  
 -- AUTO_INCREMENT for dumped tables  
 --  
   
 --  
 -- AUTO_INCREMENT for table `users`  
 --  
 ALTER TABLE `users`  
  MODIFY `id_user` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;

Relying on the users table is the table named user_settings, which I will expose while discussing the profile module. Note the user_type field will not be of much help since permission levels will not be implemented, at least not until the end of the series.

Without any transition whatsoever, let’s jump right in the registration form. There’s no point in providing a user with an interface to sign in if that user was never given the opportunity to register beforehand, right?

 /* themes/your_style/registration.php */  
   
 <div align="center">  
 <?php  
 // we first take care off displaying feedback, if it contains error messages  
 if(isset($feedback) && !is_string($feedback)){  
 ?>  
      <table border="0" cellpadding="2" cellspacing="2" align="center">  
      <ul>  
      <?php  
      foreach($feedback as $err){  
           foreach($err as $er){  
                $msgs = '';  
                $exp_msg = explode("#",$er[1]);  
                $cx = 0;  
                foreach($exp_msg as $em){  
                     if($cx < sizeof($exp_msg)-1){$trailer = '; ';}else{$trailer = '';}  
                     $msgs .= $GLOBALS['t_'.$em].$trailer;$cx++;  
                }  
                ?>  
                <tr><td><div class="response_negative" style="font-size:12px;"><li><?php echo ucfirst($GLOBALS['t_'.$er[0]]); ?> -> <?php echo $msgs; ?></div></li></td></tr>  
      <?php   
           }  
      }  
 ?>  
      </ul>  
      </table>  
      <br />  
      <?php  
 }  
 if(isset($feedback) && $feedback == 'failed'){ ?><div class="failed"><?php echo $GLOBALS['t_problem_registering_you']; ?></div><?php }  
   
 //now preparing for action urls to deploy  
 if(CLEAN_URLS == true){$url = CLEAN_PATH.'/'.CURRENT_RLINK.'/'.CURRENT_LANG;}  
 else{$url = $_SERVER['PHP_SELF'].'?'.RLINK.'='.CURRENT_RLINK.'&'.LN.'='.CURRENT_LANG;}  
   
 $utils = new UtilsModel();  
 $user_ip = $utils->get_user_ip();  
 ?>  
 <br /><br />  
 <p>&nbsp;</p>  
 </div>  
   
 <!-- the actual registration form -->  
 <form id="frm_registration" name="frm_registration" enctype="multipart/form-data" method="post" action="<?php echo $url; ?>" onsubmit="return Check_registration(this,'off');">  
       
 <table border="0" cellpadding="2" cellspacing="0" align="center">  
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_login']; ?>*</td>  
           <td align="left" class="input"><input class="text" type="text" id="login" name="login" value="<?php echo isset($_POST['login'])?htmlspecialchars($_POST['login']):""; ?>" maxlength="<?php echo MAX_CHARS_LOGIN; ?>" onkeyup="check_login_exists();" /></td>  
           <!-- pay attention to the ternary statements - if post_login is set we use it,   
           //otherwise we leave the field empty - this allows for field rememberance,   
           //so that if for any reason the form gets reloaded, the user won't have to type everything over again -->  
      </tr>  
   
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_password']; ?>*</td>  
           <td align="left" class="input"><input class="text" type="password" id="password" name="password" value="<?php echo isset($_POST['password'])?htmlspecialchars($_POST['password']):""; ?>" maxlength="<?php echo MAX_CHARS_PWD; ?>" /></td>  
      </tr>  
   
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_email']; ?>*</td>  
           <td align="left" class="input"><input class="text" type="text" id="email" name="email" value="<?php echo isset($_POST['email']) ? htmlspecialchars($_POST['email']):""; ?>" maxlength="<?php echo EMAIL_MAX_LENGTH; ?>" onkeyup="check_email_exists();" /></td>  
      </tr>  
   
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_country']; ?>*</td>  
           <td align="left" class="input">  
           <select name="country">  
           <?php   
           require('lists/countries/countries.php'); //for clarity, we use a country list  
   
                if(isset($country_list) && !empty($country_list)){  
   
                foreach($country_list as $country){                      
                     if(isset($_POST['country']) && $_POST['country'] == $country[1]){$sel = ' selected=selected';}else{$sel = '';}  
                ?>  
                     <option value="<?php echo $country[1]; ?>"<?php echo $sel; ?>><?php echo $country[0]; ?></option>  
                     <?php  
                     }  
                }   
           ?>  
           </select>  
           </td>  
      </tr>  
   
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_gender']; ?>*</td>  
           <?php  
 // if(isset($_POST['gender'])){echo $_POST['gender'];$checked = ' checked';}else{$checked = '';}   
 ?>  
           <td align="left" class="input">  
                <table border="0" cellpadding="2" cellspacing="0" width="100%">  
                     <tr>  
                          <td><input type="radio" id="gender" name="gender" value="male" checked />&nbsp;&nbsp;<?php echo $GLOBALS['t_male']; ?></td>  
 </tr><tr>  
   
                     <td><input type="radio" id="gender" name="gender" value="female"<?php if(isset($_POST['gender']) && $_POST['gender'] == 'female'){echo ' checked';} ?> />&nbsp;&nbsp;<?php echo $GLOBALS['t_female']; ?></td>  
                     </tr>  
                </table>  
           </td>  
      </tr>  
   
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_birthdate']; ?>*</td>  
           <td align="left" class="input"><input class="text" type="text" id="birthdate" name="birthdate" value="<?php echo isset($_POST['birthdate'])?htmlspecialchars($_POST['birthdate']):""; ?>" maxlength="10" onkeyup = "displayDatePicker('birthdate');" onclick = "displayDatePicker('birthdate');" /></td>  
      </tr>  
        
      <tr>  
           <td align="left" class="std"><?php echo $GLOBALS['t_newsletter']; ?></td>  
           <td align="left" class="input"><input type="checkbox" name="newsletter" value=""<?php if(isset($_POST['newsletter'])){$checked = ' checked';}else{$checked = '';} echo $checked; ?> /></td>  
      </tr>  
   
      <tr align="right">  
           <td align="center" valign="middle" class="std" valign="bottom"><?php echo $GLOBALS['t_verification_code']; ?></td>  
           <td align="center">  
                <table border="0" cellpadding="0" cellspacing="0" width="100%">  
                     <tr align="center">  
                          <td valign="middle"><img src="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES.'/'.CURRENT_THEME.'/vf_image_u.php'; ?>" />&nbsp;</td>  
                          <td><input name="vercode_u" type="text" id="vercode_u" autocomplete="off" maxlength="5" style="height:;width:155px;font-size:px;background-color:#;color:#;" /></td>  
                     </tr>  
                </table>  
           </td>  
      </tr>  
   
      <tr>  
           <td><input type="hidden" name="type" value="1" /></td>  
           <td><input type="hidden" name="ip" value="<?php echo $user_ip; ?>" /></td>  
      </tr>  
   
      <tr>  
           <td class="std" colspan="2" align="center">  
           <br />  
           <input type="submit" id="submit" name="submit" class="submit" value="<?php echo $GLOBALS['t_submit']; ?>" /></td>  
      </tr>  
 </table>  
 </form>

There really isn’t much to the above code. It starts off displaying feedback messages, if those are containing registration errors. Then the actual registration form begins.

Ternary syntax is used for field remembering. Eg:

 <input class="text" type="text" id="login" name="login" value="<?php echo isset($_POST['login'])?htmlspecialchars($_POST['login']):""; ?>" maxlength="<?php echo MAX_CHARS_LOGIN; ?>" />

This tells that if a $post login is set, let’s use it, otherwise let’s leave empty.

Client-side Javascript validation is operated by a call to the Javascript Check_registration() function that can be found in public/js/main.php. In the event that the user disables Javascript, server-side validation is triggered via the check_form_errors() method as discussed further bellow.

During both onkeyup and onclick events, a dynamic Javascript/CSS-written date picker library is instantiated and appears below the birthdate field. This library will provided be as an attachment along with the corresponding CSS file. You may choose not to use this library and it will make no difference in terms of validation, as the birthdate field is validated client-side as well as server side. This third-party open-source date picker is here to operate only as an aesthetically pleasant date picker, enhancing the overall visual aspect.

A country list file and script is used for country selection.

 <?php  
   
 /* lists/countries/coutries.php */  
   
 require('array_countries.php');  
 $country_list = array();  
 $line = array();  
   
 foreach($array_country_list as $c){  
      array_push($line, $GLOBALS['t_'.strtolower($c)], strtolower($c));  
      array_push($country_list, $line);  
      $line = array();  
 }  
 asort($country_list);  
 ?>

This snippet is pretty much self-explanatory and draws from the array bellow to create a new array containing the internationalized name of each country along with the all-lowercase formatted name of that same country.

Note the alphabetical sorting operated by the asort() function does not work too well with languages like Russian, or with html ascii codes because as of now, that’s as far as PHP’s support in that matter goes.

 <?php  
   
 /* lists/coutries/array_countries.php */  
   
 $array_country_list = array(  
 'Afghanistan',  
 'Albania',  
 'Algeria',  
  ...,  
 'Zimbabwe'  
 );  
 ?>

The full array is available as attachment, along with the English translations, to be added to languages/en/en.php

An image containing a verification code is created by vf_image_u.php using GD, as follows

 <?php  
   
 /* themes/your_style/vf_image_u.php */  
   
 session_name('general_purpose');  
 session_start(); //we will store our random number inside a session variable   
      //so we need to declare a session here too.  
   
 $text = rand(10000,99999);   
 $_SESSION["vercode_u"] = $text;   
 $height = 15;   
 $width = 45;   
    
 $image_p = imagecreate($width, $height); // check about.php in case the image does not display  
 $black = imagecolorallocate($image_p, 165, 174, 112);   
 $white = imagecolorallocate($image_p, 68, 68, 68);   
 $font_size = 14;   
    
 imagestring($image_p, $font_size, 0, 0, $text, $white);   
 imagejpeg($image_p, null, 80);   
 ?>

This simple script is using the imagecreate() function from the GD library. If the image does not display, load the about.php script that resides at root, to find out if you have GD enabled + jpeg support. We also fabricate a random number that we store inside $_SESSION[“vercode_u”].

Of course other fields can be added, some removed, that’s up to you and your project’s business logic of course, but then you need to make sure the proper fields are correctly retrieved while processing the sent data inside RegModel.php.

But from a controller point of view, this has no importance whatsoever since we will fetch our form variables programatically. Here’s how

 <?php  
   
 /* application/controllers/RegController.php */  
   
 class RegController extends BaseController{  
        
      private $module_name;  
      private $form_name;  
      private $feedback;  
                  
      public function initialize(){  
             
           $this->registry->template->module_name = $this->getModuleName();  
           $this->registry->template->form_name = $this->getFormName();  
             
           // new in our initialize() method, the intercept_data() method  
           // which will catch all form variables   
           // and send it to the relevant model method  
   
           $this->registry->template->feedback = $this->intercept_data();  
           $this->registry->template->assign_theme();  
      }  
   
      public function getModuleName(){  
           $model = RegModel::getInstance();  
           return $model->get_module_name();  
      }  
        
      public function getFormName(){  
           $model = RegModel::getInstance();  
           return $model->get_form_name();  
      }  
        
      public function intercept_data(){  
   
           // this method is where we intercept form variables  
           // to be then sent to the relevant model's method  
   
           $this->dol_posts = array();       
   
           foreach($_POST as $key => $val){//for each form variable  
   
                     // if there's a $post set of that variable,  
                     // we stack its value in the dol_posts array  
                  
                if(isset($_POST[$key])){array_push($this->dol_posts,$key);}  
           }  
             
           $model = RegModel::getInstance(); //we call an instance of the reg model  
           return $model->get_form_feedback($this->dol_posts); // and invoke the method that will process our form variables, passing them as parameter.  
      }  
 }  
 ?>

So, this controller brings us new elements that weren’t in the page controller because the logic there was different, there was no form and thus no data to be intercepted. The intercept_data() method is where we intercept form variables to be then sent to the relevant model’s method, in this case, the get_form_feedback() method belonging to the RegModel class (Singleton).

 <?php   
   
 /* from application/models/RegModel.php */  
   
 public function get_form_feedback($parms){  
             
           $util = new UtilsModel();  
   
           if(!empty($parms)){ //if we did receive form variables  
             
                $error_list = array();  
   
                // we check for form errors  
                $error_check_reg = self::check_reg_form_errors($parms);  
                //and whether login and email are unique  
                $is_unique_login = $util->check_if_unique('users', 'user_login', $_POST[$parms[0]], array('login','already_in_use'));  
                $is_unique_email = $util->check_if_unique('users', 'user_email', $_POST[$parms[2]], array('email','already_in_use'));  
   
                //if login is not unique, we stack that info into the error array  
                if (sizeof($is_unique_login) > 0){array_push($error_list,$is_unique_login);}  
   
                //same for email  
                if (CHECK_EMAIL_UNIQUE == true && sizeof($is_unique_email) == 1){array_push($error_list,$is_unique_email);}  
   
                //and for general form errors  
                if (sizeof($error_check_reg) > 0){array_push($error_list,$error_check_reg);}  
   
                //if there's at least one error found, no matter what type            
                if(sizeof($error_list) > 0){  
                     //we return our array of errors  
                     $this->form_feedback = $error_list;            
                }  
                else{  
                     //otherwise, no form errors, so we start processing the form   
                       
                     // that's the place where you make sure the form's HTML element   
                     // names you need to pull back correspond to what's in the list just bellow  
                     $field_list = array('login','password','email','country','gender','birthdate','newsletter','vercode_u','type','ip');  
                  
                     foreach($field_list as $fl){ //and for each for variable we have fetched,   
                          //if it can be found in the array above and there's a set $post variable of that name, then  
                          //we set a variable that will bare that same name, using the variable of variable ($$) syntax  
                          if(in_array($fl,$parms) && isset($_POST[$fl])){$$fl = $_POST[$fl];}  
                     }  
   
                     //building a query to insert the new user  
                     $q_insert_user = "INSERT INTO users (user_login, user_password, user_email, user_country, user_gender, user_birthdate, user_type, user_ip) VALUES ('$login', md5('$password'), '$email', '$country', '$gender', '$birthdate', '$type', '$ip')";  
   
                     // if the query executes well  
                     if(MySQLModel::get_mysql_instance()->executeQuery($q_insert_user) == 0){  
                          //we get the ID of the newly created user  
                          $q_id = "SELECT id_user, user_login,user_password FROM users WHERE user_login = '".$login."' AND user_password = md5('".$password."')";  
                          MySQLModel::get_mysql_instance()->executeQuery($q_id);  
                          $my_id = MySQLModel::get_mysql_instance()->getRows($q_id);  
   
                          if($my_id != ''){  
                               // and if everything went well and we have that ID we wanted  
                               $id = $my_id['id_user'];  
                       
                               //let's create a settings entry in db  
                               if(CURRENT_LANG){$this->lng = CURRENT_LANG;}  
                               //do not worry about the newsletter parameter because newsletters have not really been implemented  
                               //on the project. This is here only to give an effect of form completeness  
                               if(isset($newsletter)){$this->nl = 'yes';}else{$this->nl = '';}  
                            
                               //we build the query to insert a settings row for that new user  
                               $q_insert_user_settings = "INSERT INTO user_settings(user_settings_id_user, user_settings_language, user_settings_newsletter) VALUES ('$id','$this->lng','$this->nl')";  
                                      
                               if(MySQLModel::get_mysql_instance()->executeQuery($q_insert_user_settings) == 0){  
   
                                         //and if everything went according to plan, we authentify the new user                      
                                         $auth = AuthModel::getInstance();  
                                         $auth->stay_in($id,$login,$password);  
   
                                         //and then we take care of sending a 'thanks for registering - here are your credentials...' email  
                                         // we will discuss email sending via PHPMailer in a future settlement   
                                         //so you can safely skip that part for now.  
                                         require_once('languages/templates/'.CURRENT_LANG.'/'.strtolower($this->module_name).'_'.CURRENT_LANG.'.php');  
   
                                         if($regmail = $util->send_mail(CONTACT_FORM_EMAIL,$email,$GLOBALS['t_reg_email_subject'],$GLOBALS['t_reg_email_alt'],$content)){$this->form_feedback = 0 ;}  
   
                                         //In any case, our business logic requires us to relaod the page if registration turns out successful   
                                         //simply because we want the new user to automatically see a thanks for   
                                         //registering message,  
                                         //so we build a header location link and redirect the new user to that  
                                         if(DEFAULT_PLINK != ''){  
                                              if(CLEAN_URLS == true){$plink = '/'.DEFAULT_PLINK;}  
                                              else {$plink = '&'.PLINK.'='.DEFAULT_PLINK;}  
                                         }  
                                         else{$plink = '';}  
   
                                         if(CLEAN_URLS == true){$location = CLEAN_PATH.'/'.DEFAULT_RLINK.$plink.'/'.CURRENT_LANG.'/regs';}  
                                         else{$location = $_SERVER['PHP_SELF'].'?'.RLINK.'='.DEFAULT_RLINK.$plink.'&'.LN.'='.CURRENT_LANG.'&reg=success';}  
                                         header('Location: '.$location);exit();  
                                    }  
                               }  
                               else{$this->form_feedback = 'failed';} //self-explanatory  
                          }  
                               else{$this->form_feedback = 'failed';}  
                     }  
                }   
           return $this->form_feedback;  
      }  
 ?>

Very simply, what that method does is, if we did intercept our form variables, we subject them to an error checking method (that we will review further bellow), we also check for the uniqueness of the login and email fields. If errors are found we stack them into an array we return to the controller, otherwise that means all came to us clean and we then start processing that data.

We insert the new user into the database and if the query went okay, we fetch its ID and insert a row into the user_settings table for that user. We log the user in, using our AuthModel class. We do send a confirmation email, but since we will discuss email sending in a future settlement only, we leave out that part for now. And since we want the new user to get a welcome message and everything, we build a location URL through which we will reload the page.

We will take a moment to review three things though, the first one being the check_reg_form_errors() method, useful to the get_form_feedback() method, as discussed above

 <?php   
   
 /* from application/models/RegModel.php */  
   
 public function check_reg_form_errors($mr){  
           $this->reg_form_errors = array();  
   
           $line = array();            
             
           foreach($mr as $r){  
   
                if(preg_match('/login/',$r)){  
                     if(!preg_match('/^[a-z0-9_]{'.MIN_CHARS_LOGIN.','.MAX_CHARS_LOGIN.'}$/',$_POST[$r])){  
                     array_push($line,'login','not_valid');array_push($this->reg_form_errors,$line);}  
                     // as an example, 'login' and 'not_valid' are the strings we will match against   
                     //while in registration.php to help us know the encountered format for the login field is not valid  
                }  
   
                if(preg_match('/password/',$r)){  
                     if(!preg_match('/^[a-z0-9_]{'.MIN_CHARS_PWD.','.MAX_CHARS_PWD.'}$/',$_POST[$r])){  
                          array_push($line,'password','not_valid');array_push($this->reg_form_errors,$line);  
                     }       
                }  
   
                if(preg_match('/email/',$r)){  
                     if (!filter_var($_POST[$r], FILTER_VALIDATE_EMAIL)){array_push($line,'email','not_valid');array_push($this->reg_form_errors,$line);}  
                     if($_POST[$r] != '' && mb_strlen($_POST[$r]) > EMAIL_MAX_LENGTH){array_push($line,'email','not_valid');array_push($this->reg_form_errors,$line);}   
                }  
   
                if(preg_match('/birthdate/',$r)){  
                     if(!empty($_POST[$r])){  
                          if(preg_match('/^[0-9]{2}\/[0-9]{2}\/[0-9]{4}$/',$_POST[$r])){$exp_d = explode('/',$_POST[$r]);  
                          //var_dump($exp_d);  
                          if(checkdate($exp_d[0], $exp_d[1], $exp_d[2]) != 1 || !preg_match('/^[0-9]{2}\/[0-9]{2}\/[0-9]{4}$/',$_POST[$r])){array_push($line,'birthdate','not_valid');array_push($this->reg_form_errors,$line);}                                     
                          }  
                          else{array_push($line,'birthdate','not_valid');array_push($this->reg_form_errors,$line);}  
                     }  
                     else{array_push($line,'birthdate','not_valid');array_push($this->reg_form_errors,$line);}  
                }  
   
                if(preg_match('/vercode_u/',$r)){  
                     if(!preg_match('/^'.$_SESSION["vercode_u"].'$/',$_POST[$r])){array_push($line,'verification_code','not_valid');array_push($this->reg_form_errors,$line);}  
                }  
   
      $line = array();  
           }  
                //var_dump($this->reg_form_errors);  
           return $this->reg_form_errors;  
      }  
 ?>

Nothing special on that one, as it’s only about basic preg_match verification of field format. Not however that, the arrays we send back in case of found errors, correspond to the expected arrays we expect and parse in registration.php, before we display the registration form.

Second, to be able log the new user in following successful registration, we have used the stay_in() method of yet another Singleton class, the authentication class called AuthModel

 <?php   
   
 /* from application/models/AuthModel.php */  
   
 public function stay_in($id, $user, $pwd, $lang = NULL){  
      $_SESSION['c_id'] = $id;  
      $_SESSION['c_login'] = $user;  
      $_SESSION['c_pwd'] = md5($pwd);  
      $_SESSION['c_lang'] = $lang;  
 }  
 ?>

There, we simply store obviously needed credentials into session variables, so the user stays logged in as long as it still hasn’t logged out.

Third, the get_user_ip() method from UtilsModel.php that’s being called in the registration form from registration.php

 <?php  
   
 /* from application/models/UtilsModel.php */  
   
 public function get_user_ip(){  
             
      if (!empty($_SERVER["HTTP_CLIENT_IP"])){$this->real_ip = $_SERVER["HTTP_CLIENT_IP"];}  
      elseif(!empty($_SERVER["HTTP_X_FORWARDED_FOR"])){$this->real_ip = $_SERVER["HTTP_X_FORWARDED_FOR"];}  
      else{$this->real_ip = $_SERVER["REMOTE_ADDR"];}  
             
       return $this->real_ip;  
 }  
 ?>

Nothing complicated here, this snippet will go as far as it can to fetch the real IP of the user. Fetching someone’s IP is no perfect science, so bare with me and with this code until someone comes up with something even more efficient. Although, this here should get a fair share of users hiding behind proxies. But you got my point, it won’t be perfect in any case.

So anyway, our user can already register and upon successful registration gets logged in automatically. Now what if that same user has logged out but needs to log in again? Our system must offer that user a way to manually log in to the system. This is where the Signin module comes in handy. But again and for the sake of clarity, I will only be showing the relevant pieces of code. Indeed, the SignIn controller is identical to the RegController, except for a few occurrences where ‘Reg’ should be replaced by ‘SignIn’ and that’s all there’s is to it. So we will now get straight into the signin model’s get_form_feedback() method.

 <?php  
   
 /* from application/models/SignInModel.php */  
   
 public function get_form_feedback($parms){  
             
      if(!empty($parms)){ //if we did get our form values  
             
           $error_list = array();  
   
           //we check them against the check_signin_form_errors() method  
           $error_check_pwdc = self::check_signin_form_errors($parms);  
   
           if (sizeof($error_check_pwdc) > 0){array_push($error_list,$error_check_pwdc);}  
             
           if(sizeof($error_list) > 0){$this->form_feedback = $error_list;} // if errors were found, we return them  
           //otherwise, we authenticate the user, invoking AuthModel  
           else{$this->form_feedback = self::authentify($_POST[$parms[0]],$_POST[$parms[1]]);}  
           //0 for login and 1 for password  
      }  
   
      return $this->form_feedback;  
 }  
 ?>

Basically here, we validate our form data against the check_signin_form_errors() model, which looks as follows

 <?php  
   
 /* from application/models/SignInModel.php */  
   
 public function check_signin_form_errors($mr){  
           $this->signin_form_errors = array();  
   
           $line = array();            
           //var_dump($mr);  
             
           foreach($mr as $r){  
           //var_dump($r);  
                if($r == 'login'){  
                     if(!preg_match('/^[a-z0-9_]{'.MIN_CHARS_LOGIN.','.MAX_CHARS_LOGIN.'}$/',$_POST[$r])){  
                          array_push($line,'login','not_valid');array_push($this->signin_form_errors,$line);  
                     }       
                }  
   
                if($r == 'password'){//echo $_POST[$r];  
                     if(!preg_match('/^[a-z0-9_]{'.MIN_CHARS_PWD.','.MAX_CHARS_PWD.'}$/',$_POST[$r])){  
                          array_push($line,'password','not_valid');array_push($this->signin_form_errors,$line);  
                     }       
                }  
   
      $line = array();  
           }  
   
           return $this->signin_form_errors;  
      }  
 ?>

This method acts exactly the same way as check_reg_form_errors(). But if everything goes okay, we authenticate the user by calling the authentify() method from the same class.

 <?php   
   
 /* from application/models/SignInModel.php */  
   
 public function authentify($login,$password){  
      $auth = AuthModel::getInstance();  
      $this->authentified = $auth->identify($login,$password);  
   
      return $this->authentified;  
 }  
 ?>

This method called for the identify() method kept in AuthModel.php, which looks just like this bellow

 <?php  
   
 /* from application/models/AuthModel.php */  
   
 public function identify($user,$pwd){  
             
           $default_plink = '';  
   
           if(DEFAULT_PLINK){  
                if(CLEAN_URLS == true){$default_plink = DEFAULT_PLINK.'/';}  
                else{$default_plink = '&'.PLINK.'='.DEFAULT_PLINK;}  
           }  
             
          $q_auth = "SELECT id_user,user_login,user_password   
                     FROM users   
                     WHERE user_login = '".$user."'   
                     AND user_password = md5('".$pwd."')  
                ";  
   
           MySQLModel::get_mysql_instance()->executeQuery($q_auth);  
           $my_auth = MySQLModel::get_mysql_instance()->getRows($q_auth);  
             
           if($my_auth != ''){       
                  
                $id = $my_auth['id_user'];  
                $this->identified = 'yes';  
                  
                //once the user has been authenticated, we go fetch its private language settings  
                $user_lang = "SELECT id_user_settings, user_settings_id_user, user_settings_language   
                        FROM user_settings   
                        WHERE user_settings_id_user = '".$id."'  
                        ";  
                  
                MySQLModel::get_mysql_instance()->executeQuery($user_lang);  
                  
                $userlang = MySQLModel::get_mysql_instance()->getRows($user_lang);  
   
                if($userlang != ''){$this->user_lang = $userlang['user_settings_language'];}  
   
                //and write the user to a session                 
                $this->stay_in($id, $user, $pwd, $this->user_lang);  
                  
                // IF LAST URL REMEMBERED  
                if(isset($_SESSION['last_url']) && $_SESSION['last_url'] != ''){  
                     $exp_url = explode("&",$_SESSION['last_url']);  
                     $xpr = LN.'=';  
                     $parts = '';  
                     $rep = LN.'='.CURRENT_LANG.'&';  
                       
                     foreach($exp_url as $xpurl){       
                          if(preg_match('/'.$xpr.'/',$xpurl)){  
                               if($xpurl_new = preg_replace('/'.$xpr.'/',$rep,$xpurl)){$parts .= $rep;}  
                          }  
                     else{$parts .= $xpurl.'&';}  
                     }  
                       
                     if(preg_match('/signin/',$_SESSION['last_url']) || preg_match('/fpwd/',$_SESSION['last_url'])){  
                          if(CLEAN_URLS == true){$location = CLEAN_PATH.'/'.DEFAULT_RLINK.$default_plink.'/'.CURRENT_LANG;}  
                          else{$location = $_SERVER['PHP_SELF'].'?'.RLINK.'='.DEFAULT_RLINK.$default_plink.'&'.LN.'='.CURRENT_LANG;}                           
                     }  
                     else{$location = rtrim($parts,"&");}  
                }  
                else{  
                     if(CLEAN_URLS == true){$location = CLEAN_PATH.'/'.DEFAULT_RLINK.'/'.$default_plink.CURRENT_LANG;}  
                     else{$location = $_SERVER['PHP_SELF'].'?'.RLINK.'='.DEFAULT_RLINK.$default_plink.'&'.LN.'='.CURRENT_LANG;}  
                }  
                header('Location: '.$location);exit();  
           }  
           else{$this->identified = 'wrong_credentials';}  
             
           return $this->identified;  
      }  
 ?>

If you have survived these series up until now, you should not need an explanation for this last snippet, but just in case though… : once we have identified the user we go fetch its ID and language than determine the location to which we will redirect that user, based on whether a last URL was recorded and whether clean URLS are enabled or not.

Finally, now that our user has been able to log in manually, that same user may be wanting to review and update its personal data. This is just what profile module is all about. The profile module, which is alike the settings one, only differs from let’s say the signin module in that we need to get the user’s data in order to present it in the profile form.

 <?php  
      /* from application/controllers/ProfileController.php */  
   
      ...  
      // while in properties  
      private $user_data;  
      ...  
   
      ...  
      //while inside the initialize() method, after the intercept_data() method, and before assign_theme()  
      $this->registry->template->user_data = $this->getProfileFormData(); //we call the method right bellow  
      ...  
        
      private function getProfileFormData(){  
           $model = ProfileModel::getInstance();  
           return $model->getProfileFormData(); //we call and returns the method we need  
      }  
      ...  
 ?>

and so, in the profile model we have

 <?php  
   
      /* from application/controllers/ProfileModel.php */  
   
      public function getProfileFormData(){  
             
           $this->user_profile=array();  
        
           //data for the profile module resides in the users table       
           $my_query_profile = "SELECT * FROM users WHERE id_user = '".$_SESSION['c_id']."' AND user_login = '".$_SESSION['c_login']."'";  
             
           MySQLModel::get_mysql_instance()->executeQuery($my_query_profile);  
             
                $this->up = MySQLModel::get_mysql_instance()->getRows($my_query_profile);  
                  
                if($this->up != ''){  
                     array_push($this->user_profile, $this->up['user_login'],$this->up['user_email'],$this->up['user_country'],$this->up['user_birthdate']);  
                }  
                  
                return $this->user_profile;  
      }  
 ?>

It also differs in that once we have intercepted our form data, we need to update the database with it, and here is how we will do it

 <?php  
   
      /* from application/controllers/ProfileModel.php */  
   
      public function get_form_feedback($parms){  
             
           if(!empty($parms)){  
             
                $error_list = array();  
   
                $error_check_profile = self::check_profile_form_errors($parms);  
   
                if (sizeof($error_check_profile) > 0){array_push($error_list,$error_check_profile);}  
             
                if(sizeof($error_list) > 0){  
                     $this->form_feedback = $error_list;            
                }  
                else{            
                     $field_list = array('login','password','email','country','birthdate');  
                  
                          foreach($field_list as $fl){  
                               if(in_array($fl,$parms) && isset($_POST[$fl])){$$fl = $_POST[$fl];}  
                          }  
                  
                     $now = date("Y-m-d H:i:s");  
   
                     $q_update_profile = "UPDATE users   
                          SET user_email = '".$email."',  
                          user_country = '".$country."',  
                          user_birthdate = '".$birthdate."',  
                          user_timestamp = '".$now."'  
                          WHERE user_login = '".$login."'  
                          AND user_password = md5('".$password."')  
                          AND user_timestamp != '".$now."'  
                     ";                 
   
                     if(MySQLModel::get_mysql_instance()->executeQuery($q_update_profile) == 0){  
                          if(MySQLModel::get_mysql_instance()->affectedRows() == 1) {$this->form_feedback = 'success';}  
                          else{echo MySQLModel::get_mysql_instance()->mysql_fetch_errors();$this->form_feedback = 'wrong_password';}  
                     }  
                     else{$this->form_feedback = 'failed';}  
                }  
             
           }            
                return $this->form_feedback;  
      }  
 ?>

You can see it’s very similar to any other get_form_feedback() methods from other models, only here we update the data. Note the use of the field user_timestamp which exists only to force MySQL to affect something if one of the values has then changed. Otherwise, if the update is performed and no rows were affected, there’s no programatic way to know it worked and so our code could only return a failed state, or nothing at best.

Regarding the profile form in profile.php, its structure appears to be no different than the registration form. You will only have to make sure your HTML form field names correspond to what is being processed in the model. On the model side, the check_profile_form_errors() methods is similar to check_reg_form_errors() so there’s no point repeating the same code over and over and besides, this will be a great exercise for you to test the knowledge you have acquired so far from these series.

By the way, let’s take a look at the user_settings table, because you will need it too

 --  
 -- Table structure for table `user_settings`  
 --  
   
 CREATE TABLE `user_settings` (  
  `id_user_settings` int(11) NOT NULL,  
  `user_settings_id_user` int(11) NOT NULL,  
  `user_settings_language` enum('de','es','fr','nl','ru','se','uk','en') NOT NULL DEFAULT 'en',  
  `user_settings_nipp` enum('10','15','20','50','75','100','150') NOT NULL DEFAULT '15',  
  `user_settings_newsletter` varchar(3) NOT NULL,  
  `user_settings_timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP  
 ) ENGINE=MyISAM DEFAULT CHARSET=latin1;  
   
 --  
 -- Dumping data for table `user_settings`  
 --  
   
 INSERT INTO `user_settings` (`id_user_settings`, `user_settings_id_user`, `user_settings_language`, `user_settings_nipp`, `user_settings_newsletter`, `user_settings_timestamp`) VALUES  
 (1, 1, 'fr', '20', '', '2015-11-19 08:05:46');  
   
 --  
 -- Indexes for dumped tables  
 --  
   
 --  
 -- Indexes for table `user_settings`  
 --  
 ALTER TABLE `user_settings`  
  ADD PRIMARY KEY (`id_user_settings`);  
   
 --  
 -- AUTO_INCREMENT for dumped tables  
 --  
   
 --  
 -- AUTO_INCREMENT for table `user_settings`  
 --  
 ALTER TABLE `user_settings`  
  MODIFY `id_user_settings` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;

Note the user_settings_nipp and newsletter fields are only here for demonstration, so you may remove them but as long as you modify your settings model accordingly of course.

Finally and regarding the forgotten password module or the change password module, there is nothing magical about them, the fpwd module is somehow very identical to the signin module and the pwdc module is relatively similar to the signin module too. Knowing that should get you on track faster while you attempt at building those new modules. Note that regarding the fpwd module, an email is sent with a new password, you may use the generate_new_pwd() method from UtilsModel.php.

Now we could not be coming full circle if we did not get in the subject of authentication again. Why? Simply because users should not be allowed to enter their profile data unless they are already logged in, which makes sense. So that, the first call inside the initialize() method of your profile controller will be to the get_module_auth() method, as described bellow

 <?php  
      /* from application/controllers/ProfileController/php */  
        
      public function initialize(){  
   
           $utils = new UtilsModel();            
           $this->registry->template->module_auth = $utils->get_module_auth();  
           ...  
      }       
 ?>

Now the function get_module_auth() method itself, pretty much and explicit one.

 <?php  
   
      /* from application/models/UtilsModel/php */  
   
      public function get_module_auth(){  
        
           if(CURRENT_PLINK){  
                if(CLEAN_URLS == true){$pg = '/'.CURRENT_PLINK;} else{$pg = '&'.PLINK.'='.CURRENT_PLINK;}  
           }  
           else{$pg = '';}       
                       
           if(isset($_SESSION['c_login']) && isset($_SESSION['c_pwd']) && $_SESSION['c_login']!='' && $_SESSION['c_pwd']!=''){  
                $this->module_auth = 0;  
           }  
           else{  
                $this->module_auth = 1;  
                if(CLEAN_URLS == true){$location = CLEAN_PATH.'/signin/'.CURRENT_LANG;}  
                else{$location = $_SERVER['PHP_SELF'].'?'.RLINK.'=signin&'.LN.'='.CURRENT_LANG;}  
                header('Location: '.$location);exit();  
           }  
      }  
 ?>

And that wraps up this fifth settlement dedicated to building a user interface that allows someone to register, sign in, review and update profile. From this, you can now easily extend what you have already learned to build a settings module, same as a profile module but that will rely on the user_settings table, a fpwd module that will handle cases of forgotten passwords and even a pwdc module, that will allow users to change password, first checking of course on the validity of the password they enter, then checking that the new and confirm new passwords are of correct format and match each other too.

Next time I will get into full detail as to the subject of theme and language handling, reviewing all aspects of what makes the visual identity of this project and also discuss a method for localizing strings.

This article first appeared Thursday the 7th of January 2016 on RolandC.net.

Google Analytics tracking code not being detected anymore and/or real-time tracking not working?

noreply@blogger.com (rolandc.net) — Wed, 03 Jun 2015 12:36:00 +0000

Today I am going to show you a simple trick so you can avoid a few hours of head-banging while trying to fix your Google Universal Analytics code not being detected anymore and/or erase the frustration of having a real-time feature menu taking up half the left-hand panel but that always shows only one data - '0'.

How to convert online guitar tabs to Midi to import into Guitar Pro/Tux Guitar

noreply@blogger.com (rolandc.net) — Fri, 02 Jan 2015 10:16:00 +0000

Not earlier than last night, I was confronted to the challenge of having to convert a guitar tab I found on the internet, to MIDI format, so it could be read by TuxGuitar.

Indeed, I had just wanted to effortlessly check if the tab I was reading exactly sounded like I needed.

Effortlessly? well not quite so, but in the end I was able to come up with a reliable method which allows one to import a tab into TuxGuitar, play it and/or then export it to whatever format is available, gp5 for example, all legally and free of charge.

The operation is really easy, and to prove it, let's start with, say....something that looks like this:


E||------2--0-2---2-------2--0-2---2---|------3--2-3---3-------3--2-3---3---|
B||------------------------------------|----0--------0---0---0--------0---0-|
G||----2--------2---2---2--------2---2-|------------------------------------|
D||-------------------0----------------|-------------------0----------------|
A||------------------------------------|------------------------------------|
D||--0---------------------------------|--0---------------------------------|

 
------3--2-3---3-------3--2-3---3---|------2--0-2---2-------2--0-2---2---|
----2--------2---2---2--------2---2-|----3--------3---3---3--------3---2-|
------------------------------------|------------------------------------|
-------------------0----------------|-------------------0----------------|
------------------------------------|------------------------------------|
--0---------------------------------|--0---------------------------------|

Tab junkies should have already recognized the piece, Bach's Cello Suite №1 Prelude. The simple trick I found after three hours playing with converters that never worked, was to use this free online tab converter . I did not even have to register and it's completely free.

Step 1

Just copy-paste the tab you have found in the second box. I would not recommend importing directly as a file, as you might get a parsing error. Click on upload.

Step 2

Now time to select an option or two. For my piece, Medium (default option) was too slow so choosing Medium fast did the trick. Also, I have had to select the option Ignore spacing and play notes equally so it rendered times normally. Once done then click on Go at the bottom right corner

Step 3

At this point, all you have to do is to click the blue arrow you can see on the top right corner, this will have you save your data into a .pl file.

Step 4

Assuming you are using TuxGuitar (should not be too different for Guitar Pro users), go to File->Import->Import Midi and select the .pl file you have just downloaded.

By now, you should be able to play your tab, do any necessary modifications and re-import if necessary, and, you should be able to save or export your tab to any format you like, eg .gp3, .gp4, .gp5, .tg, you name it.

Note: In case you have trouble playing the tab because you get an error that the Jack audio server cannot be started, don't go disabling pulseaudio or do anything that will impair sounds on your system. Just go to your settings menu (Tools->Settings->Sound), and select a difference audio server interface.

In TuxGuitar, it would look like this:

All you would have to do would be to choose the (default) TG Fuidsynth port and Tux Guitar Sequencer or anything else that's available on your system.

So now, you should be able to (legally, effortlessly and at no cost) import guitar tabs found online to your favorite Guitar tab program. Enjoy your tabs!

How to build your own Multilingual PHP MVC CMS from scratch - Part 4 - Frontend (part 2): Menu System

noreply@blogger.com (rolandc.net) — Sun, 28 Dec 2014 09:00:00 +0000

Welcome to the fourth settlement of our tutorial series on how to build your own Multilingual MVC CMS from scratch and in which, this time, we will lay our hands on the front-end menu system.

The last time, we have covered the complete building of the (front) page module, going from the database page table up to page.php, in which the required page content is displayed. In between, we have exposed and explained the page controller and its corresponding model, while also demonstrating, among other things, a way to create and instantiate a Singleton class. All of which having resulted in the making of our first complete and fully functional module that allows the user, upon manually loading the correct URL in the browser, to fetch and display on screen a requested page.

But although doing this works perfectly well, one cannot expect nowadays to have users always 'hard-type' the URL of the resource they seek in their browsers. That is one of the reasons why menus have generally been accepted as an extremely important feature of modern Web development. Since the aim of any CMS is by nature to make the programmer/administrator's life easier while trying to meet the most functionality that's the most frequently asked for in the Web creation industry, we're going to do just that: to implement a menu system in our CMS.

Note however, before we begin, that each forthcoming settlement will tend to reflect the CMS's own business logic gradually more, rather than get to explain the same PHP-OOP language features over and over again. This does make sense since we have already reviewed the most part of the core object model on which our project is based.

Our menu system will have its own back-end management module, which we will be covering in a future settlement only. But for now, we will set our focus onto its front-end side, starting from the database model and going all the way to visual display.

So let's jump into the database model first. Basically, from a back-end point of view, the administrator will have the possibility to create, edit and delete whole menus. What this means for us on the front-end side is that, at any time, there could be any number of menu tables in the database, named menus_1, menus_2 and menus_3, etc... . Each menu table containing any number of menu rows (entries).

Still on the front-end side, two types of graphical menu layouts will be available for now, both relying on Javascript/CSS via third-party scripts, one of which displaying a layout of vertical type (menu_tree.php) and the other one, of horizontal type (hmenu.php). Both menu layouts being multilevel, meaning they will support an unlimited number of levels.

The Javascript files for those libraries are named respectively dtree.php and hmenu.js and reside in public/js. As for CSS, they are named dtree.css and hmenu.css and can be found in themes/your_style/css. Theme icons for the dtree library will be set inside its Javascript file, but will be found in themes/your_style/servicing/dtree. Icons for the hmenu library will be found in themes/your_style/servicing/hmenu.

Now, In config.php, we will have to manually determine which menu table is to be assigned to either of those two graphical menu types, as shown bellow

define("MENU_TREE_MENU_TABLE","1");
define("HMENU_MENU_TABLE","2");

As an example, the value "1" simply corresponds to the table named menus_1 and "2" to menus_2.

There is definitely room for new graphical layout types or more of the existing ones, as long you declare the corresponding constants in config.php, at least to keep everything clean there. That said, in nowadays internet, Websites displaying more than two graphical menus at once on the same page are not that frequently encountered.

In any case, now is a good time to reveal the structure of our menu_# tables

--
    -- Table structure for table `menus_1`
    --
    
    CREATE TABLE IF NOT EXISTS `menus_1` (
    `id_menu_1` smallint(6) NOT NULL,
      `menu_1_rank` varchar(12) NOT NULL,
      `menu_1_type` varchar(60) NOT NULL,
      `menu_1_page` varchar(60) DEFAULT NULL,
      `menu_1_position` smallint(6) NOT NULL,
      `menu_1_display` enum('no','yes') DEFAULT NULL
    ) ENGINE=MyISAM AUTO_INCREMENT=43 DEFAULT CHARSET=latin1;
    
    --
    -- Dumping data for table `menus_1`
    --
    
    INSERT INTO `menus_1` (`id_menu_1`, `menu_1_rank`, `menu_1_type`, `menu_1_page`, `menu_1_position`, `menu_1_display`) VALUES
    (1, '1#0', 'page', 'hours', 1, 'yes'),
    (2, '2#0', 'page', 'products', 2, 'yes'),
    (3, '3#0', 'page', 'about_us', 3, 'yes'),
    (4, '4#0', 'page', 'directions', 4, 'yes');
    
    --
    -- Indexes for dumped tables
    --
    
    --
    -- Indexes for table `menus_1`
    --
    ALTER TABLE `menus_1`
     ADD PRIMARY KEY (`id_menu_1`);
    
    --
    -- AUTO_INCREMENT for dumped tables
    --
    
    --
    -- AUTO_INCREMENT for table `menus_1`
    --
    ALTER TABLE `menus_1`
    MODIFY `id_menu_1` smallint(6) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=5;

We can tell by the menus_#_display field that each menu row can either be chosen for display displayed or not.
You may already be recognizing the menu_#_type field, which corresponds the module type since our menu system will only be linking modules.
Row ranks (menu_#_rank) hold a special format [1 to 2 figures + # + 1 to 2 figures], and a row rank with 0 as right side value means it is a top-level row. No menu_rank entry can hold a 0 on its left side.
A parent-kid relation is obtained by having the right side of the kid's rank being equal to the left side of the parent's rank.
Modules other than the page or the elink module will have 0 as menu_#_page value since they don't need a page or elink. Elink will be the module that takes care of External links, used in case we need to link an external URL to a menu row.

That is all we need to know for now regarding the menu model at database level. So now we will be turning to MenuModel.php, and see how we will format our database menu table data to properly supply both our tree and horizontal menu layouts the feed formats they require.

<?php
    /* application/models/MenuModel.php */    

    class MenuModel{ 
        //Instantiating our class which appears to be a Singleton one again
    
        static $instance;    //declaring properties
        private $menu_items;
        private $module_name;
        private $items_translation_line;    
        private $items_translations;
    

        public static function getInstance(){ 
            //creating and returning a single static instance of the class for when invoked
            if(self::$instance ==  null)
                self::$instance = new self();
            return self::$instance;
        }
    
        public function __construct(){} //disallowing the creation of a new instance
        private function __clone(){} // disallowing cloning
    
        public function get_module_name(){ //returns the module name
            return $this->module_name = 'menu';

        }    
    
        public function getMenuItemsData($mtp, $direction = NULL){ //$mtp is the mumber of the menu we seek
            //this method fetches and prepares the database data needed to feed the menu layout  
            
            $util = new UtilsModel();
    
            // we first get all the exist menu tables
            $get_all_tables = $util->show_tables(DBNAME,'menus'); 
    
            if(in_array($mtp,$get_all_tables)){ // if the menu we seek exists 
    
                $mtp = "_".$mtp;
                $myitems = '';
    
                $menu_label_translations = self::getTreeMenuItemTranslations(CURRENT_LANG,'page'); // we fetch all page name translations for the current language (this will be useful when the module name is 'page')
                $menu_label_translations_elink = self::getTreeMenuItemTranslations(CURRENT_LANG,'elink'); // same for elinks but we do not need to worry about it for now
    
                //we select all the rows meant for display, order them by position, ascending 
                $my_menu_items = "SELECT id_menu".$mtp.", menu".$mtp."_rank, menu".$mtp."_type, menu".$mtp."_page 
                                     FROM menus".$mtp." 
                                     WHERE menu".$mtp."_display = 'yes' 
                                     ORDER BY menu".$mtp."_position ASC
                                   ";        
                
                MySQLModel::get_mysql_instance()->executeQuery($my_menu_items);
            
                if(MySQLModel::get_mysql_instance()->affectedRows() > 0){ //if we found at least one row

                    $ct_top_menus = 0;
    
                    while($myitems = MySQLModel::get_mysql_instance()->getRows($my_menu_items)){    
                        //while we pull and stack each found row in $myitems
    
                        if($myitems['menu'.$mtp.'_type'] == 'page'){//if row type equals page
                            
                            $mt = trim($myitems['menu'.$mtp.'_page']); //we fetch its formatted page name
                            $cv = 0;                
    
                            foreach($menu_label_translations as $mlt){
    
                                if(!in_array($mt,$mlt)){$cv++;}
                                else{
                                        //and fetch its non-formatted internationalized name to stack it in $menu_text, 
                                        //which corresponds to the menu label that will be displayed on screen
                                        if($mlt[1] == CURRENT_LANG){$menu_text = $mlt[2];
                                }
                            }
                        } 
    
                            if($cv == sizeof($menu_label_translations)){ // if no non-formatted name has been found
                                if(isset($mt) && $mt != ''){$mt = $mt.' - ';} // if there was a page
                                else{$mt = '';}
        
                                // we assign a missing page string to $menu_text
                                $menu_text = $mt.$GLOBALS['t_page_missing'];
                            }
                        }
    
                        elseif($myitems['menu'.$mtp.'_type'] == 'elink'){    // same for elinks but again, we do not need to worry about it for now
    
                            $mt = trim($myitems['menu'.$mtp.'_page']);
    
                            $cv = 0;                
    
                            foreach($menu_label_translations_elink as $mlt){
    
                                if(!in_array($mt,$mlt)){$cv++;}    
                                else{if($mlt[1]== CURRENT_LANG){$menu_text = $mlt[2];}
                            }
                        } 
    
                            if($cv == sizeof($menu_label_translations_elink)){
                                if(isset($mt) && $mt != ''){$mt = $mt.' - ';}else{$mt = '';}
                                $menu_text = $mt.$GLOBALS['t_page_missing'];
                            }
                        }
    
                        elseif($myitems['menu'.$mtp.'_type'] == 'sign'){ 
                                // if row type equals sign (this is the sign-in/out module)
    
                            //if the user is looged in
                            if(isset($_SESSION['c_login']) && isset($_SESSION['c_pwd']) && $_SESSION['c_login'] != '' && $_SESSION['c_pwd'] != ''){
                                // we assign 'signout', internationalized as menu label
                                $menu_text = $GLOBALS['t_'.$myitems['menu'.$mtp.'_type'].'out'];
                            }
                            else{
                                    //otherwise, if not logged in, we assign 'signin', internationalized
                                    $menu_text = $GLOBALS['t_'.$myitems['menu'.$mtp.'_type'].'in'];}
                    }
                    else{ //otherwise, for any other module type

                        if(isset($GLOBALS['t_'.$myitems['menu'.$mtp.'_type']])){
                            // if it exists, we assign the internationalized name of the module to $menu_text
                            $menu_text = $GLOBALS['t_'.$myitems['menu'.$mtp.'_type']];

                        }
                        else{
                                //otherwise we assign a missing module string
                                if($myitems['menu'.$mtp.'_type'] != ''){
                                    $menu_text = $myitems['menu'.$mtp.'_type'].' - '.$GLOBALS['t_module_missing'];
                                }
                                else{$menu_text = $GLOBALS['t_module_missing'];}
                        }
                    } 

                    // if row type equals to registration and the user is logged in, we do nothing
                    if($myitems['menu'.$mtp.'_type'] == 'reg' && isset($_SESSION['c_login'])){} 

                    else{
                            //otherwise, we append the elements (separated by #) of each row (separated by @@) to $this->menu_items, 
                            //so that our feed will be string, not an array.
                            $this->menu_items .= $myitems['menu'.$mtp.'_rank'].'#'.html_entity_decode($menu_text).'#'.$myitems['menu'.$mtp.'_type'].'#'.$myitems['menu'.$mtp.'_page'].'@@';
                            //at this point, our feed is ready for use in menu_tree.php
                    }

                    if(preg_match('/[0-9]#0#/',$this->menu_items)){ //if this menu row corresponds to a top-level menu entry
                        $ct_top_menus++; //we increment the top menu counter by 1
                    }
                }

                if($ct_top_menus == 0){//if no top menus found
                    return $this->menu_items = 'no_top_menu'; //we return just that
                }

                if(isset($mtp) && isset($this->menu_items) && isset($direction) && $direction == 'hmenu'){ 
                    // if the call to this method was issued from hmenu.php, therefore, 
                    // if we need to be able to process our feed in our horizontal layout, 
                    // we first transform it to an array of menu rows

                    $hmenu_exp = explode("@@",rtrim($this->menu_items,"@@"));

                    $menu = array();
                    $line = array();

                    foreach($hmenu_exp as $he){ // and then for each menu row

                        $exp_he = explode("#",$he); //we explode the row

                        array_push($line,$exp_he[0],$exp_he[1],$exp_he[2],$exp_he[3],$exp_he[4]); //we stack everything in a $line array
                        array_push($menu,$line); //and stack each $line in a $menu array
                        $exp_he = array(); //we unset $exp_he and $line
                        $line = array();
                    }
                    krsort($menu); // we sort the $menu array by key
                    $this->menu_items = self::rebuild_menu($menu); //we call the rebuild_menu() method.
                }
            }
            else{    
                    // if menu exists but no row was found in it
                    $this->menu_items = 'menu_empty';
            }
        }
        else{
                //if the menu we seek does not exist
                $this->menu_items = 'menu_missing';
            }
        return $this->menu_items;
        }
    
        public function getTreeMenuItemTranslations($ln, $pfx){ //passing current language and table name as paramaters
    
            MySQLModel::get_mysql_instance()->set_char('latin1');
    
            // creating a query to retrieve all pages or elinks whose language corresponds to the current one
            $q_retrieve_pages = "SELECT * FROM ".$pfx."s 
                                 WHERE ".$pfx."_language = '".$ln."'
                                ";
    
            $this->items_translation_line = array();
            $this->items_translations = array();
    
            MySQLModel::get_mysql_instance()->executeQuery($q_retrieve_pages);
    
                while($mypage = MySQLModel::get_mysql_instance()->getRows($q_retrieve_pages)){ // while we have results
                    array_push($this->items_translation_line, $mypage[$pfx.'_name_formatted'], $mypage[$pfx.'_language'], $mypage[$pfx.'_name']); //we stack them in the $this->items_translation_line array
                    array_push($this->items_translations, $this->items_translation_line); //and stack $this->items_translation_line into $this->items_translations
                    $this->items_translation_line = array(); 
                }
            return $this->items_translations; //and return all processed rows
        }
    
        public function rebuild_menu($menu){ 
            //called inside the getMenuItemsData() method

            $new_menu = array();
            $new_m = array();
    
            foreach($menu as $m){ //foreach menu row
    
                //we rebuild/duplicate the row in a brand new row array called new_m
                array_push($new_m,$m[0],$m[1],$m[2],$m[3],$m[4]);
    
                $kids = self::check_if_kids($m[0],$menu); //and we check if the current row has kids 
    
                //if we found some, we add them to the new row array ($new_m)
                if(sizeof($kids) > 0){array_push($new_m,$kids);}
     
                array_push($new_menu, $new_m); //we stack the new row array into the $new_menu array
                $new_m =  array(); // we empty each new row to avoid redundancy
            }
            return $new_menu; //we return the complete menu set, ready for use in hmenu.php
        }
        
        public function check_if_kids($id, $menu){

            $kids = array();
            $kids_line = array();
    
            foreach($menu as $v){    
                if($id == $v[1]){ //if the current row is a kid to someone, we check whether that kid is not itself a parent 
                    if(sizeof(self::check_if_kids($v[0], $menu)) > 0){ 
                        //if it turns out that that kid indeed has kids
                        ksort($menu); //sorting
                        array_push($kids_line,$v[0],$v[1],$v[2],$v[3],$v[4],self::check_if_kids($v[0], $menu)); // here we use recursion:
                        //we add them to the $kids_line array we're building
                    }
                    else{
                        //otherwise we build our kid line but without adding kids because that kid hasn't any    
                        array_push($kids_line,$v[0],$v[1],$v[2],$v[3],$v[4]);
                    }
                    //and we stack each kid line in the $kid array
                    array_push($kids,$kids_line);    
                    
                    $kids_line = array(); // we override the $kids_line array()
                }
            }
            return $kids; //we return all kids 
        }
    }
    ?>

So basically, the MenuModel class first checks whether the menu we seek does exist, then fetches all its displayable rows (if found any) and builds a thread for each one, based on row type (menu_type). That thread includes, but not limited to, either the localized module name, or, if the module equals to page, the localized non-formatted page name that has been assigned to it. The '#' sign is used to separate row items and '@@' is used to separate rows.

At that point, our feed is ready for use in menu_tree.php, but if the model is being called from hmenu.php, meaning, if we need to be able to process our feed in our horizontal menu, we then first transform it to an array of menu rows, and turn each row to an array of row items, then stack all items into a new $line array which itself is being stacked into a new $menu array. We then rebuild the $menu array using the rebuild_menu() method. This is the method that will restore hierarchy between all rows. It takes a $menu array as sole parameter and for each row traversed, calls upon the check_if_kids() method to simply check if the then-menu row does have kids.

The check_if_kids() method is a recursive one, which, if it finds that the kid it then traverses has kids of its own, adds them to a new row array it is building, all while iterating through those new kids and so on. Otherwise, it does not add anything and is building a regular row array with no kids in it. A resulting kid array is returned to the rebuild_menu() method which again returns us a feed we can use, but in hmenu.php this time.

The show_tables() method allows, based on a database name and a table name pattern, to spot any table that follows that pattern. It is called in getMenuItemsData() and we use it to retrieve all existing menu tables. It is part of the UtilsModel class and appears to be pretty much self-explanatory.

/* from application/UtilsModel.php */

    Class UtilsModel....

    public function show_tables($db_name, $pattern){

        $all_menu_tables = "SHOW TABLES FROM ".$db_name;

        MySQLModel::get_mysql_instance()->executeQuery($all_menu_tables);

        $this->all_table_indexes = array();

        while($tables = MySQLModel::get_mysql_instance()->getRows($all_menu_tables)){
            $table_name = $tables['Tables_in_'.$db_name];    
            if(preg_match('/^'.$pattern.'_.*$/',$table_name)){
                //note the carret sign at the end of the regex, so we don't pick admin_menu_tables alongthe way.
                $exp_table_name = explode("_",$table_name);
                $index = end($exp_table_name);    
                array_push($this->all_table_indexes, $index);
            }        
        }
    return $this->all_table_indexes;
    }

Now is a great time to uncover our tree menu layout, located in menu_tree.php. As stated earlier, it relies on an open-source Javascript/CSS script, which in fact is called dTree, written by Geirs Landrö and attached to this settlement. But between our feed and this script, there is a lot to be done to ensure our tree menu layout is correctly being handled.

Let's take a look at menu_tree.php

<?php
$menu_tree = new MenuModel();
$dmenu = $menu_tree->getMenuItemsData(MENU_TREE_MENU_TABLE,''); //'1','2','3' - leave parameter #2 to avoid extra processing - this type of menu does not need it

if(isset($dmenu)){ 
    
    if($dmenu == 'menu_missing'){
        ?>
        <div class="failure"><?php echo $GLOBALS['t_menu_nb'].MENU_TREE_MENU_TABLE; ?> <?php echo $GLOBALS['t_is_missing_from_db']; ?></div> 
    <?php }
    
    elseif($dmenu == 'no_top_menu'){ 
    ?>
    <div class="failure"><?php echo $GLOBALS['t_menu_nb'].MENU_TREE_MENU_TABLE; ?> - <?php echo $GLOBALS['t_no_top_menu_detected']; ?></div>
    <?php }

    elseif($dmenu == 'menu_empty'){ 
    ?>
    <div class="failure"><?php echo $GLOBALS['t_menu_nb'].MENU_TREE_MENU_TABLE; ?> <?php echo $GLOBALS['t_exists_but_is_empty']; ?></div>
    <?php }

    else{
        
        if(CURRENT_LANG){$ln = CURRENT_LANG;} else{$utils = new UtilsModel(); $ln = $utils->get_default_lang();}
        
        $default_plink = '';

        if(CLEAN_URLS == true){
            if(DEFAULT_PLINK){$default_plink = DEFAULT_PLINK.'/';}
            $home_link = CLEAN_PATH.'/'.DEFAULT_RLINK.'/'.$default_plink.$ln;
            $out = "/out";
        }
        else{
            if(DEFAULT_PLINK){$default_plink = '&'.PLINK.'='.DEFAULT_PLINK;}
            $home_link = $_SERVER['PHP_SELF'].'?'.RLINK.'='.DEFAULT_RLINK.$default_plink.'&'.LN.'='.$ln;
            $out = "&".LETOUT."=yes";
        }
        $home = $_SERVER['PHP_SELF'];

        $rlink = RLINK;
        $plink = PLINK;
        $ln = LN;
        $cur_ln = CURRENT_LANG;
        
        if(isset($_SESSION['c_login'])){$c_login = $_SESSION['c_login'];}else{$c_login = "";}
        ?>
        <table border="0" cellspacing="0" cellpadding="0" class="dtree">
        <div class="dtree">
        
            <script type="text/javascript">
            var home = "<?php echo $home; ?>";
            var homelink = "<?php echo $home_link; ?>"; 
            var home_label = "<?php echo $GLOBALS['t_home']; ?>"; 
            var dmenu = "<?php print(htmlspecialchars($dmenu)); ?>";
            var arosplit = dmenu.split("@@");
            var dmenu2 = '';
            var rlink = "<?php echo $rlink; ?>";
            var plink = "<?php echo $plink; ?>";
            var ln = "<?php echo $ln; ?>";
            var cur_ln = "<?php echo $cur_ln; ?>";
            var c_login = "<?php echo $c_login; ?>";
            var out = "<?php echo $out; ?>";
            var clean_urls = "<?php echo CLEAN_URLS; ?>";
            var clean_root = "<?php echo CLEAN_PATH.'/'; ?>";
                <!--

                d = new dTree('d'); //we create a new tree object called d

                d.add(0,-1,home_label,homelink);  //we add the home node/menu

                 for (i = 0;i<arosplit.length; i++){    //for each menu line    
                     
                    var tlink = "";
                    var olink = "";
                     
                    dmenu2 = arosplit[i];
                    sharpsplit = dmenu2.split("#");
                       
                    if(sharpsplit[3] == "page" || sharpsplit[3] == "elink"){ // if type = page or type = elink
                        if(clean_urls == true){tlink = "/" + sharpsplit[4];}
                        else{tlink = "&" + plink + "=" + sharpsplit[4];}
                    }
                      else{if(sharpsplit[3] == 'signin'){if(c_login != ''){olink = out;}}
                    }               
                    if(clean_urls == true){
                        if(sharpsplit[3] != undefined){ //then add the other nodes
                            d.add(sharpsplit[0],sharpsplit[1],sharpsplit[2], clean_root + sharpsplit[3] + tlink + olink + "/" + cur_ln); 
                        }
                    }
                    else{
                        d.add(sharpsplit[0],sharpsplit[1],sharpsplit[2], home + "?" + rlink + "=" + sharpsplit[3] + tlink + olink + "&" + ln + "=" + cur_ln);
                    }
                  }
                      
                document.write(d); //we print out the tree

                //-->
            </script>
        </div>
        </table>
        <?php unset ($plink);
    }
}
?>

So, from the moment we drew our menu feed to store it inside $dmenu, we first echo missing menu messages and alike, if any, then we take care off the default language, default page link and start building our home link since we're not yet looping through the menu rows we have. Note that only the tree menu will have a home link feature, proper to itself. It will of course be possible to add a home link to the horizontal menu, but it will have to be a regular type of link. We then start gathering all the PHP variables we need and pass them to Javascript to help build the menu nodes(rows). We instantiate a tree using the dTree() method from the third-party tree menu library we use and start adding the home link by invoking the add() method of that library. Then, looping through each menu row, we dynamically build and add the rest of the nodes. Finally, we display the resulting tree on screen. Again, the proper dTree Javascript/CSS library files would be provided as attachments. Note that these libraries have been modified to support clean URL's and also so that you can bring you own icons and style along the way.

Last, but not least, hmenu.php.

<?php
$hmenu = new MenuModel();
$menu = $hmenu->getMenuItemsData(HMENU_MENU_TABLE,'hmenu'); // Leave 'hmenu' as is, to have the db result set undergo extra processing to make it fit with this kind of menu.

if(isset($menu) && is_string($menu) && $menu == 'menu_missing'){ 
    ?>
    <div class="failure"><?php echo $GLOBALS['t_menu_nb'].HMENU_MENU_TABLE; ?> <?php echo $GLOBALS['t_is_missing_from_db']; ?></div>
<?php }
if(isset($menu) && is_string($menu) && $menu == 'menu_empty'){ 
    ?>
    <div class="failure"><?php echo $GLOBALS['t_menu_nb'].HMENU_MENU_TABLE; ?> <?php echo $GLOBALS['t_exists_but_is_empty']; ?></div>
<?php }
if(isset($menu) && is_string($menu) && $menu == 'no_top_menu'){ 
    ?>
    <div class="failure"><?php echo $GLOBALS['t_menu_nb'].HMENU_MENU_TABLE; ?> - <?php echo $GLOBALS['t_no_top_menu_detected']; ?></div>
<?php }

if(isset($menu) && is_array($menu)){
?>
<ul class="hmenu" id="hmenu">
<?php
$letout = ''; 

foreach($menu as $m){
 //foreach menu line    
    $child = $m[0];
    $parent = $m[1];
    $translation = $m[2];
    $type = htmlspecialchars($m[3]);
    $page = htmlspecialchars($m[4]);

    if($type == 'page' && $page != '0'){
        if(CLEAN_URLS == true){$pg = '/'.$page;}
        else{$pg = '&'.PLINK.'='.$page;}
    }
    elseif($type == 'elink' && $page != '0'){
        if(CLEAN_URLS == true){$pg = '/'.$page;}
        else{$pg = '&'.PLINK.'='.$page;}
    } 
    else{$pg = '';}
     
    if($type == 'signin'){
        if(!isset($_SESSION['c_login']) || $_SESSION['c_login'] == ''){
            //$type = 'signin';
            $letout = '';
        }
        else{
            //$type = 'signin'; 
            if(CLEAN_URLS == true){$letout = '/out';}
            else{$letout = '&'.LETOUT.'=yes';}
        }
    }
//if(isset($m[5])){sort($m[5]);}
    if($parent == '0'){
        //IF TOP MENU, WE DISPLAY IT
        if(CLEAN_URLS == true){$url = CLEAN_PATH.'/'.$type.$pg.$letout.'/'.CURRENT_LANG;} 
        else{$url = SITE_URL.'?'.RLINK.'='.$type.$pg.'&'.LN.'='.CURRENT_LANG.$letout;}
        ?>
        <li>
            <a href="<?php echo $url; ?>" class="hmenulink"><?php echo $translation;
            
            if(isset($m[5]) && sizeof($m[5]) > 0){// if the topmenu has kids, we add a decorative arrow
                ?>&nbsp;<img src="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES.'/'.CURRENT_THEME; ?>/images/servicing/hmenu/down-arrow.png" width="9" height="5" />
        <?php } ?></a>

        <?php
            if(isset($m[5]) && sizeof($m[5]) > 0){//and we call the get_kids() function to display them
                $ml = 0;
                ksort($m[5]);                        
                echo get_kids($m[5],$child, $ml);             
            }
        ?>
        </li>
        <?php
        }
    }
    ?>
</ul> 
<script type="text/javascript">
    var hmenu = new hmenu.dd("hmenu");
    hmenu.init("hmenu","menuhover");
</script>
<?php 
}

function get_kids($kid, $child, $ml){

    krsort($kid); //to test
    $letout = '';
    
    $feed = '<ul class="hmenu" id="hmenu">';    

    foreach($kid as $k){
         //for each kid
            
        $par = $k[1];
        $ch = $k[0];
        $tr = $k[2];
        $ty = htmlspecialchars($k[3]);
        $pag = htmlspecialchars($k[4]);

        if($ty == 'page' && $pag != '0'){
            if(CLEAN_URLS == true){$pg = '/'.$pag;}
            else{$pg = '&'.PLINK.'='.$pag;}
        }
        elseif($ty == 'elink' && $pag != '0'){
            if(CLEAN_URLS == true){$pg = '/'.$pag;}
            else{$pg = '&'.PLINK.'='.$pag;}
        } 
        else{$pg = '';}

        if($ty == 'signin'){
            if(!isset($_SESSION['c_login']) || $_SESSION['c_login'] == ''){
                //$ty = 'signin';
                $letout = '';
            }
            else{
                //$ty = 'signin';
                if(CLEAN_URLS == true){$letout = '/yes';}
                else{$letout = '&'.LETOUT.'=yes';}
            }
        }
                
        if($par == $child){
            if(CLEAN_URLS == true){$url = CLEAN_PATH.'/'.$ty.$pg.$letout.'/'.CURRENT_LANG;}
            else{$url = SITE_URL.'?'.RLINK.'='.$ty.$pg.'&'.LN.'='.CURRENT_LANG.$letout;}

            $feed .= '<li>';
            $feed .= '<a href="'.$url.'" class="shmenulink2">'.$tr;
        
            if(isset($k[5])){// if kids, we add an arrow
                $feed .= '&nbsp;<img src="'.CLEAN_PATH.'/'.PATH_TO_THEMES.'/'.CURRENT_THEME.'/images/servicing/hmenu/down-arrow.png" width="9" height="5" alt="'.$tr.'" /></a>';
            }
    
            if(isset($k[5])){$feed .= get_kids($k[5],$ch, $ml);}    //recursion
            $feed .= '</li>';
        }
    }
    $feed .= '</ul>';
    return $feed;
}
?>

For the most part, hmenu.php, as highlighted in the comments, does just what menu_tree.php does, but there are important differences though. Its layout is partly being drawn here, as opposed to menu_tree.php, which has its layout being entirely drawn inside the dTree library. Most importantly too, this is here we will use recursion while looking for kids.

In hmenu.php, if we find a top row, we display it, and if that top row has kids, we not only add a decorative arrow ourselves, but we do call the get_kids() function, which, since its a recursive one, will, upon finding new kids, call itself back. Once the loop is complete, we call on our third-party horizontal library to create a menu object called hmenu, passing our new structure as parameter, and initialize that object passing the relevant CSS class names as parameters.

So now, we have a fully functional front-end menu system working for us, which offers a choice of two layouts, vertical and horizontal. Both support an infinite number of levels and are totally customizable by means of CSS and Javascript too. This menu system will now on allows us to hierarchically present our pages and modules nicely, without having the users hard-typing their URL in their browsers. In a future settlement, I will show you how to build the back-end management module that will allow the creation/edition/deletion of those menu rows as well as the menus itself.

But next time, we will set our focus on how to handle the user experience by creating a sign module along with a user profile module, that will allow the user to get into its personal account interface and update personal data.

This article first appeared Sunday the 28th of December 2014 on RolandC.net.

How to build your own Multilingual PHP MVC CMS from scratch - Part 3 - Frontend (part 1): Page Module

noreply@blogger.com (rolandc.net) — Wed, 05 Nov 2014 21:07:00 +0000

Welcome to the third settlement of our tutorial series on how to build your own Multilingual MVC CMS from scratch and in which we will be creating our first entire module, the page module.

Last time, we have set the focus on the index.php file, responsible for routing user input, calling all the needed core components that we have previously reviewed.
We have seen how the Router class, which can be assimilated as a factory, once instantiated and invoked by means of its own route() method, generates and triggers, based on user input, a new controller object that itself, aided by the __autoload() function from the index file, calls on the name-matching module class it needs in order to get all the logic and data it will use to build the needed view and it does so by relying on the $registry object that was passed onto it while being instantiated by the $router object, the $registry object containing a template object, itself containing a method to include the needed view file as well as a __set() method to store all the template variables the controller needs to pass to the view file, in order to be used by the programmer there.

So today, we are going to take a dive straight into the page module, see how its controller, model and view really work on the ground. But before we start with the page controller class, let's take a brief look at the structure of the database table called 'pages', which contains all the data we will rely on to effectively handle pages in our CMS.

 --  
      -- Table structure for table `pages`  
      --  
      CREATE TABLE IF NOT EXISTS `pages` (  
      `id_page` smallint(6) NOT NULL,  
       `page_data` mediumtext,  
       `page_name_formatted` varchar(60) NOT NULL,  
       `page_name` varchar(80) NOT NULL,  
       `page_language` varchar(2) NOT NULL,  
       `page_created` datetime DEFAULT CURRENT_TIMESTAMP,  
       `page_last_edited` datetime DEFAULT CURRENT_TIMESTAMP  
      ) ENGINE=MyISAM AUTO_INCREMENT=0 DEFAULT CHARSET=latin1;  
      --  
      -- Indexes for dumped tables  
      --  
      --  
      -- Indexes for table `pages`  
      --  
      ALTER TABLE `pages`  
       ADD PRIMARY KEY (`id_page`), ADD FULLTEXT KEY `pages_data` (`page_data`);  
      --  
      -- AUTO_INCREMENT for dumped tables  
      --  
      --  
      -- AUTO_INCREMENT for table `pages`  
      --  
      ALTER TABLE `pages`  
      MODIFY `id_page` smallint(6) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=0;  
      /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;  
      /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;  
      /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Note that the field called page_name_formatted, since it corresponds to the formatted name of the page that will be either be displayed in the URL or serve inside menu links, to play it safe, will always need to contain nothing but lowercase, latin-alphabet letters and/or figures, with only underscore/minus signs allowed. Also, page_language will always have to contain two lowercase letters only.

Here is a dummy data sample for you to insert in your own page table

 INSERT INTO 'pages' ('id_page', 'page_data', 'page_name_formatted', 'page_name', 'page_language', 'page_created', 'page_last_edited') VALUES  
      (1, 'data for page 1', 'page_1', 'Page 1', 'en', '2014-09-06 23:05:39', '2014-09-06 23:53:19'),  
      (2, 'data for page 2', 'page_2', 'Page 2', 'en', '2014-09-06 23:06:42', '2014-09-06 23:55:28'),  
      (3, 'data for page 3', 'page_3', 'Page 3', 'en', '2014-09-06 23:07:18', '2014-09-06 23:58:02')  
      );

So now, without further waiting, here comes our PageController class

 <?php  
      /* application/controllers/PageController.php */  
      class PageController extends BaseController{   
           //Declaring our PageController class  
           //This class benefits from the properties of the abstract parent class it extends, called BaseController,   
           //but even though the parent class forces us to have an initialize() method set here,   
           //it is up to us programmers to decide how we wish to implement it here.  
           //declaring our private properties  
           private $module_name; //passed to main.php to validate the including of page.php  
           private $page_data; // passed to page.php as containing the actual data stored in the DB for the particular page the user seeks   
           private $page_name; //passed to header.php to serve inside the meta title tag  
           private $page; // only this property will not be passed directly to the view,   
           //instead, it will hold the value of plink and be passed as a parameter to the model's get_data() method   
           //Note: those properties will not be passed as-is to the view, not from here at least, so we can confidently keep them as private while here.  
           public function initialize(){ // this is the method our abstract BaseController class forces us to declare  
                //Next we issue a few calls to some methods that will in turn call upon the model to get the needed data  
                //and we store the results as properties of the template object (remember the Template class contains a __set() method too)   
                //The template object is being itself stored as a property of the registry object  
                $this->registry->template->module_name = $this->getModuleName();  
                $this->registry->template->page_data = $this->getPageData();  
                $this->registry->template->page_name = $this->getPageName();  
                //note the $this keyword which specifies that we refer to this class only  
                //finally, we call the assign_theme() method from the template object,   
                //that method will take care off preparing the above properties for display,   
                //plus it will include our common template files (header, main and footer)  
                $this->registry->template->assign_theme();  
           }  
           public function getModuleName(){  
                // we instantiate our PageModel class, which is Singleton, so we need to use the :: syntax and call its getInstance() method to do so.   
                $model = PageModel::getInstance();  
                //and we simply call its get_module_name() method, which will simply return the name of the module, as a string.  
                return $model->get_module_name(); //We return than name  
           }  
           public function getPageName(){  
                // same operation with the get_page_name() method, which will return   
                // the non-formatted localized name of the page from the DB  
                $model = PageModel::getInstance();  
                return $model->get_page_name();  
           }  
           public function getPageData(){  
                if(CURRENT_PLINK){$this->page = CURRENT_PLINK;}  
                else{$this->page = DEFAULT_PLINK;}   
                // we assign whatever plink value we have fetched in the index   
                // otherwise we assign the default plink value  
                $model = PageModel::getInstance(); //we instantiate our PageModel class again   
                return $model->getData($this->page,CURRENT_LANG);   
                // and call the getData() method (passing the URL page name and current language as parameters),  
                // which will fetch the page content from the DB for us. We return the result of the call  
           }  
      }  
      ?>

We start by declaring our PageController class and declare the few properties we will need along the way. Only the top three properties will be passed to the view.

Then we call the initialize() method, the top three properties: module_name, page_data and page_name are being passed to the view, as they are being assigned the results of specific method calls to the PageModel object, by being added to the template object, which itself had been added to the registry object as a property and which also contains a __set() method allowing it to store the properties to be then passed to the view.

Finally we call the assign_theme() method from the template object. That method will prepare the above properties for display and it will include our common template files as well: header.php, main.php and footer.php.

Then remains the actual calls to some of the PageModel's methods. Those in this particular case are the calls that feed the values of our above properties, the ones we want to pass to the view. The PageModel class is a Singleton one and so we need to access and instantiate it by using the :: syntax, plus by making a call to its public and static getInstance() method. The calls to our model's methods are not made directly though. While still inside the initialize() method, we issue a call to a dedicated controller method that will itself invoke the needed model's method.

So now has come the time to lay our PageModel class down on the table.

 <?php  
      /* application/models/PageModel.php */  
      class PageModel{ //declaring our PageModel class  
           static $instance;     // needed to help make the class a Singleton one  
           private $module_name;       
           private $pageData;  
           private $page_name;  
           public static function getInstance(){ //method to create a single static instance of this class,   
                //which will be accessed from anywhere outside the class using the :: operator.   
                //It can be called anything you wish.  
                if(self::$instance == null){ // if no instance was created  
                     self::$instance = new self(); // we create one   
                     //the keyword 'self' reffers to the current class  
                }  
                return self::$instance; //returning the newly created instance  
           }  
           private function __construct(){}   
           private function __clone(){}  
           //Those two methods are here to prevent the programmer from creating a second instance of this class by using the new() or clone() methods.   
           //Only one instance of this class will be accessible and it will be accessible using the getInstance() method only.   
           //This is how Singleton classes are built.  
           public function get_module_name(){ //the method that will set and return the module name we need in main.php   
                //If $module_name has been set and passed to main.php, then page.php will be included   
                //in main.php, where we need it to graphically appear.  
                $this->module_name = 'Page'; //setting the value of the module_name property,   
                //which has not yet been turned to a variable by the template object   
                return $this->module_name; //returning that value  
           }                 
           public function get_page_name(){   
           //method to get the non-formatted, localized name of the page  
                if(CURRENT_PLINK){   
                     // if plink has been set in the URL and is not empty  
                     //we instantiate MenuModel (also a Singleton)  
                     $menu_instance = MenuModel::getInstance();  
                     $page_list = $menu_instance->getTreeMenuItemTranslations(CURRENT_LANG,'page');   
                     //and fetch the list of all existing pages found in DB 'pages' table.   
                     //This is a method that originally serves other purposes,   
                     //but since part of the data it returns contains all the data we need here,   
                     //we save ourself writing an extra method by using it.  
                     $cv = 0; //we initialize a counter  
                     foreach($page_list as $pl){ foreach known front-end page  
                          if(!in_array(CURRENT_PLINK,$pl)){$cv++;}   
                               //if our page name cannot be found inside the currently   
                               //looped page from the DB, we increment $cv by 1.  
                          else{   
                                    //otherwise, that means our page name is valid  
                                    if($pl[1] == CURRENT_LANG){$this->page_name = $pl[2];  
                                    //and once the current language is being matched, we assign   
                                    //the corresponfing non-formatted page name to the page_name property  
                               }  
                          }  
                     }   
                     if($cv == sizeof($page_list)){ // if the page name could not be found while looping the array above,//we build a missing link instead and assign it to the to the page_name property  
                          $this->page_name = CURRENT_PLINK.' ('.$GLOBALS['t_'.CURRENT_LANG.') - '.$GLOBALS['t_page_missing'];  
                     }  
                }  
                else{$this->page_name = ''; //if no page name was set, we assign it an empty string value}  
                return $this->page_name; //we return the page name, whatever its value  
           }       
           public function getData($page, $ln){ //we declare the function, taking page name and language as parameters  
                $this->pageData = array(); //we declare the array that will hold our page data from the DB  
                $page = filter_var($page,FILTER_SANITIZE_MAGIC_QUOTES); //we use the PHP native filter_var function to sanitize our page name.   
                //This is primarily a matter of security as we don't want issues related to SQL Injection attacks   
                //by means of manually (deliberately?) placing quotes or double quotes in the URL to or in place of the page name.  
                MySQLModel::get_mysql_instance()->set_char('latin1'); //we invoke our MySQL library's set_char() method   
                //to avoid encoding issues with the content we pull here. Latin1? yes, more on that in a future settlement though.   
                $my_query = "SELECT id_page, page_name, page_data   
                              FROM pages WHERE page_name_formatted = '".$page."'   
                              AND page_language = '".$ln."'  
                            ";   
                //we build a query in which we select all entries of which the formatted named and language correspond respectively to our current page and language names. Only one single row should be found as a result.  
                MySQLModel::get_mysql_instance()->executeQuery($my_query);  
                // we instantiate our MySQL instance and execute the query  
                $res = MySQLModel::get_mysql_instance()->getRows($my_query);  
                // and we pull what's been found, assign it to $res  
                if($res != ''){ //If what's been found isn't empty  
                     array_push($this->pageData, $res['page_data'], $res['page_name']); //we stack it insde the pageData array  
                }            
                else{ //otherwise  
                          if(isset($page) && $page != ''){ $page = stripslashes($page).' ('.$GLOBALS['t_'.$ln].')';}   
                          else{$page = '';}   
                          //we stack a missing page message in the pageData array,   
                          //that will include the image file name of the missing page sign we will display in the view.  
                          array_push($this->pageData, $page.$GLOBALS['t_page_missing'],'missing_page2.png');  
                }  
                return $this->pageData; //and we return whatever we have picked up and stacked in the pageData array.  
           }  
      }  
      ?>

The PageModel class is a Singleton one. I have described in the comments the way a Singleton class can be built, by declaring a public static function that will create a single static instance of the class every time it will be called. But, to remain a Singleton, the class needs to be declared empty __construct() and __clone() methods so that a second instantiation cannot be initiated by the programmer, even mistakingly.

The get_page_name() method checks if page name (CURRENT_PLINK) is set and not empty, then pulls a list of all existing pages and sees if it finds it there. If it does, it assigns the page's non-formatted and localized name to the page_name property, and if it does not, it assigns a missing page message to that same property. And if page name is not set, it assigns an empty string to page_name. For the sake of this tutorial however, you may skip checking with the existing page list and simply return the value of CURRENT_PLINK, provided it is set and not empty.

Now, in the getData() method, we set the page_data property as an array, modify the database charset to 'Latin1' and sanitize the $page parameter from the method call using PHP's native filter_var() function. Then we build a query string to pull the page table entry that matches our current page and language names and simply execute that query. In the page_data array, we stack the fields we need from the freshly pulled results. And if results there aren't, we stack a missing page message in it, along with the name of the missing page image file we will display with the message.

The page model contains fairly simple methods and its role can mostly be summed up as simply pulling content from the page table, based on page name and current language. It seems therefore fair to warn the reader on that most of the models we will soon be dealing with are not that simple in content and/or architecture. But have no fear, as we have about reviewed the core structure of the architecture we're going to be evolving in, from now the difficulty level should not be increasing that significantly. However and by nature, some of the models we will be reviewing soon will present algorithms of which the explanation might not appear to be so obvious to all readers at first. In any a case, both code comments and explanations will make up for it, so that you will never really have to worry about the growing complexity of the project.

Back one level up in our page module hierarchy, now that we have pulled the page data we needed from the DB and returned it to the controller, we're all set to call the assign_theme() method, which will transform some of our controller's properties to regular variables/arrays we can actually use inside the theme files.

Let's first take a look at a sample from main.php

 <?php  
      /* themes/your_theme_name/main.php */  
      ...   
      <td>  
           <?php  
                try{     //we do use a try/catch bloc with this kind of include  
                          if(isset($module_name) && !empty($module_name)){   
                                    //if the controler has passed us the module_name property   
                                    //and provided it's not empty, we then use it to include the corresponding view file  
                                    $path = PATH_TO_THEMES.'/'.CURRENT_THEME.'/'.strtolower($module_name).'.php';  
                                    include $path;  
                          }  
                          else {  
                                    //else we throw an exception containing whatever message we need to visually display  
                                    throw new Exception('<p>&nbsp;</p><p>&nbsp;</p><div class="loading_tpl_fails">'.$GLOBALS['t_the_theme_named'].' <u>'.$module_name.'</u> '.$GLOBALS['t_couldnt_be_found'].'</div>');  
                          }  
                }  
                catch(Exception $e){  
                     echo $e->getMessage();  
                     exit(0);  
                }  
           ?>  
      </td>  
      ...  
      ?>

The main.php file is the place where page.php will actually be included, as again, it will not be included straight from the assign_theme() method of the template object. We do use a try/catch bloc to wrap this include statement.

And now, let's see what page.php has to tell us

 <?php  
      /* themes/your_theme_name/page.php */  
      <?php  
      // See how we find back our controller properties here,   
      // transformed to regular variables or arrays, holding the value(s) we have assigned them  
      // while still in the initialize() method of the controller  
      if(isset($page_data[1]) && preg_match('/missing_page/',$page_data[1])){ //if the required page is missing  
      ?>   
           <img src="<?php echo CLEAN_PATH.'/'.PATH_TO_THEMES.'/'.CURRENT_THEME.'/'; ?>images/servicing/<?php echo $page_data[1]; ?>" />  
           //we display a missing page image (remember we stacked the image   
           //file name inside the page_data array while in the model   
           //then returned it to the controller and passed it onto the view here)  
           <p>&nbsp;</p>  
           <?php  
           }  
           if(isset($page_data[0]) && is_string($page_data[0]) && !preg_match('/missing_page/',$page_data[0]) ){   
                //if the required page is not missing and its value does not match 'missing_string'  
                ?>  
                <div align="center">  
                <?php   
                     print $page_data[0]; //we print the data we had stacked in the page_data array  
                ?>  
                </div>  
           <?php   
      }  
      ?>       
      <br />  
      ?>

We can now clearly see how we find back and use our controller properties while inside the view, eg: page_data, transformed to regular, usable PHP array, holding the value(s) we assigned it while we were still in the initialize() method of the controller.
As for the algorithm of the overall page template, it is very simple: if the required page is missing, we display a missing page image with a missing page string underneath, otherwise, we display the content we have pulled from the DB for the required page.

By now and by having gathered all code from this part as well as from the last one, referring to the first part for directory structure information too, you should already have a basic application that allows you to display a page based on URL input. For now though, we have only been discussing the page module.

But as an example, loading http://localhost/your_project_name/index.php?q=page&page=page_3&ln=en into your browser, if successful, should serve your screen three template files, namely header.php, main.php and footer.php, with main.php containing page.php, itself containing the DB-pulled content for page_3 (provided page_3 is not missing from the DB). If page_3 is missing from the DB, a missing image will be displayed and you are free to choose an image for yourself to work with. The page.php file can be placed everywhere it would graphically makes sense to you, as long as it stays inside main.php.

Note that for clarity reasons I have not been including header.php and footer.php in the series yet but for now, you can make up for it by adding some simple header and footer files, header.php file containing the usual html, header tags we all know about. This is where you will link your main theme CSS file, and if your style name is called pinguin, then your main CSS file would have to be called pinguin.css. The favicon file will be stored in /themes/your_style/images/favicon and be called favicon.ico. The main.php file will contain the first body tag and footer.php will contain the closing body and html tags. This way, you can start effectively styling your project while we're getting advanced but still haven't reviewed all the theme-handling aspects of our project yet. Those will be the subject of a whole forthcoming settlement.

Last but not least, in case this wasn't implicit enough: every time you encounter a global variable of the form : $GLOBAL['t_variable_name'], this means, by the very standards of this project, that this is a translation variable and that basically, in the language file pertaining to the current language (languages/current_language/current_language.php) should exist a variable called $t_variable_name = 'Translation string';. Otherwise a missing variable error is being thrown by PHP. Again, language-handling will be discussed in more details in a forthcoming settlement.

Meanwhile, do not hesitate to refer to your copy of Gumbo you have probably downloaded already last week. This will hopefully help you solidify your understanding of the project we're building together.

So this completely wraps up this settlement on how the page module works, bottom up. Next time, we will get our hands tied on yet another generally essential - not to say vital - feature in Web development, the menu system.

This article first appeared Tuesday the 5th of November 2014 on RolandC.net.

How to build your own Multilingual PHP MVC CMS from scratch - Part 2 - Starting Point: index.php

noreply@blogger.com (rolandc.net) — Wed, 29 Oct 2014 05:35:00 +0000

Welcome to this second settlement of our tutorial series on how to build your own Multilingual MVC CMS from scratch and in which we will be discussing the entry point of our application: The index.php file.
During the first part, we have, among other things, reviewed the core principles around which we will develop our project and also briefly introduced its directory structure.
But now, all those would be totally useless if not for one single file, the one and only entry point of our application, the index file, responsible for handling user input, requiring all the needed components along the way and which we are now going to decorticate, step by step.

Gumbo-CMS is the application on which these series are based

Before we start: I have based these series entirely on Gumbo-CMS, the new Multilingual PHP5 MVC CMS in town, which I have recently released under the GPL V2 License. So feel free to download yourself a copy before we actually get started, as it will contain every single snippet of code you will be able to find throughout the entire tutorial. This will provide you with some guidance if you ever get lost during one of the forthcoming settlements. Equally, you will find useful insights as to which kind of feature Gumbo-CMS offers by taking a look at its Product Overview PDF.

So, we jump right in by declaring a session on line 2, just below the opening php tag and we also include our config file.

 <?php  
      //we initiate a session, useful for user sessions handling,
      // last visited URLs, etc.
      session_start();   
      //and we include our config file
      include 'config.php';

Next, we instantiate the UtilsModel class, which contains a few useful 'all-purpose' functions.

 // we instantiate our general-purpose class called UtilsModel
 $utils = new UtilsModel();

Then we define our timezone.

 date\_default\_timezone_set(DDTS); // we define our timezone

DDTS will be the config constant that holds our timezone value, eg: Europe/Stockholm, Europe/Paris. This is required since PHP 5.10 because otherwise, I quote from the php.net site : 'every call to a date/time function will generate a E_NOTICE if the timezone isn't valid, and/or a E_WARNING message if using the system settings or the TZ environment variable'. Alternatively, you can also set the date.timezone parameter in php.ini.

 /*recording the last visited url*/  
      if(isset($_GET[RLINK]) && $_GET[RLINK] != 'signin' && $_GET[RLINK] != 'fpwd' && $_GET[RLINK] != 'fpwd'){  
           //if a module is set and that is neither the signin model nor the forgotten password one, we store the request URI in a session variable  
           $_SESSION['last_url'] = $_SERVER['REQUEST_URI'];  
      }

This above is a snippet that pertains to the logic of our CMS, in regard to the recording of the last visited URL. This is also a good occasion to start introducing the URL constant naming scheme we will be using throughout the whole project while developing it.

RLINK, implicitly meaning Router Link, is the constant that holds the $_GET name of a module name, be it current or sought after. Equally important are PLINK and LN, which will respectively hold page and language names.

The value of all URL constants can be modified to taste, as long as the CLEAN_URLS constant is set to false. This because of the rewrite rules in .htaccess that will not allow the dynamic naming of target variables within its rules. But as long as clean URLS aren't enabled, you are free to give any value you wish to your URL $_GET variables.

Let's break away momentarily from the index.php file to take a look at this extract from config.php

 /* config.php */  
      ...  
      define("CLEAN_URLS",false); //true or false. true to enable it, false to disable - NOTE : mod_rewrite has to be enabled for it to work. We will set it to true when we reach our settlement about setting up clean URL's, so for now, let's keep it disabled  
      /*routing*/  
      define("RLINK","q"); //Router Link- var that holds the current module name in $_GET requests - make sure it's different from the other url variables found in this file, and different from google cse reserved terms (cx, language, sa, etc...) - use 'ctrl + F' to check within this file  
      define("DEFAULT_RLINK","page");          // Warning: if you choose a default module that's different from the page module,  
      define("DEFAULT_PLINK","formatted_name_of_the_page_you_wish");     //Page Link     // then you will have to leave the DEFAULT_PLINK value blank;  
      define("PLINK","p");  
      ...

But back to our little snippet in the index (commented as 'recording the last visited url'), what it says is: If a module is set and that module is different from the signin module and different from the forgotten password module too, we then store the REQUEST URI in a session variable we call $_SESSION['last_url']. We do this because we simply don't want to have the user automatically come back to the login screen or the forgotten password procedure once it has successfully logged in.

And now has come the time to call and instantiate some of our core classes, namely the router, registry and template classes.

 /* requiring the core clases */  
      require_once('application/Router.php');   
      require_once('application/Registry.php');  
      require_once('application/Template.php');  
      /* instantiating them */  
      $router = new Router();  
      $registry = new Registry();  
      $registry->template = new Template(); // here we add the new template object to the registry object, as one of its properties

The router will do the work of routing user input by retrieving the requested GET variable, then including and calling the corresponding controller, based on the value of that variable. We will review what the router actually does in detail when the route() function is called later in the the file.

We call on the registry, which contains magic __set() and __get() methods: this will simply provide a registry to our application in which to store some of our application variables.

We also call and instantiate the template class, adding it to our registry object as one of its properties and which contains our template engine. It will store both the variables assigned by the controller for the view to use and include the view itself.

 /* DB connection initiating */  
      MySQLModel::get_mysql_instance()->newConnection(DBHOST,DBUSER,DBPWD,DBNAME,DBPORT);   
      // we instantiate our Singleton MySQLModel class and invoke the newConnection() method, passing our config's db settings as parameters

To connect to and interact with the MySQL database, we will use a custom MySQLModel class, which I have found on the Internet and turned into a Singleton class, so its instantiation gets restricted to one object only and which we will be able to access via the get_mysql_instance() method, every time we need to perform an operation with the database.

Singleton? Yes. Design patterns, in the software development industry, are patterns that have been observed, tried and accepted as being the most likely solutions to a set of commonly encountered problems, so that you do not have to reinvent the wheel and implementing solutions to commonly encountered patterns is somehow the best way you can use to make sure you're being on the right track, at least on the same track as most others.

The Singleton pattern is a very popular software design pattern that's very useful in our case. Our MySQLModel class does not need and shall not be instantiated more than once, all while it will still be able to perform its duties CMS-wide.

Having made our MySQLModel class a Singleton one allows us, once loaded, to access it from anywhere using the :: syntax, thus we do not have to store our database connection inside a global variable, a session variable or whatever else.

Using the MySQLModel::get_mysql_instance()->newConnection(params) syntax, we simply instantiate our class and add a call to the newConnection() method altogether, passing our database connection constants from the config file as parameters. Since the call is made early enough in our index file, we do not need to perform any additional connection anywhere else. We will only need to use the MySQLModel::get_mysql_instance()->method_name(params); syntax every time we need to perform an operation with MySQL.

Note that even though we have named our class the MySQL model, we do connect to MYSQL via the mysqli extension.

Next, we engage in pre-routing user input, or what remains of it. Up to Gumbo-CMS v0.96beta (included), pre-routing was operated by means of header redirects, under the logic that we always wanted to have a valid module link (RLINK) and a valid language link (LN) defined at a minimum in the URL, at any time.

Now bare with me, Google does not like header redirects, even though they claim 302 status is fine for them, so you will have all the trouble of the world trying to index your site using such (security?) procedure. While the Bing engine will index your code just fine, Google's spiders will not because they see these kinds of redirects as hijacking attempts. Which is why v.97 features a new pre-routing approach which does not use PHP headers at all.

In this new approach, we will simply determine a value for PLINK, RLINK and LN and assign those to constants, respectively CURRENT_PLINK, CURRENT_RLINK and CURRENT_LANG

 /* pre-routing (or what's left of it) */  
      
      $plink = ''; 
      // if there is a $_GET[PLINK] set, let's use it
      if(isset($_GET[PLINK])){$plink = $_GET[PLINK];}
      // otherwise let's use DEFAULT_PLINK
      else{$plink = DEFAULT_PLINK;}
      // whatever what set, we assign it to CURRENT_PLINK, to use it wherever needed, whenever needed
      define("CURRENT_PLINK",$plink);  
      
      $rlink = '';  //same here for RLINK, with the difference that :
      // we use a module name list stored in config.php to check if that 
      // if we have a module set in URL, it has to be a valid module name
      $exp_menu_type_list = explode(";", MENU_TYPE_LIST);  
      if(isset($_GET[RLINK]) && in_array($_GET[RLINK], $exp_menu_type_list) ){$rlink = $_GET[RLINK];}  
      // otherwise, we use the default RLINK value, namely DEFAULT_RLINK 
      else{$rlink = DEFAULT_RLINK;}
      // same as for PLINK, we store what we have in a constant  
      define("CURRENT_RLINK",$rlink);  
      
      $dlang = $utils->get_default_lang(); //we need to fetch the default language 
      $available_languages = LocModel::getInstance()->getData_language_bar(); // we also need a list of the currently existing language in the database 
      
      // Since the available language list we've just fetched contains more than what we need
      // we create an array in which we will store just the elements we seek 
      $available_language_codes = array();   
      foreach($available_languages as $a_l){array_push($available_language_codes, $a_l[0]);}  
      
      // Now, if a language is set in the URL, AND is a valid language (made of only 2 lowercase letters) 
      // AND can be traced in our available language codes array we've just filled in, 
      // then it's all a valid language that we will store in $langf
      if(isset($_GET[LN]) && preg_match('/^[a-z]{2}$/',$_GET[LN]) && in_array($_GET[LN], $available_language_codes)){$langf = $_GET[LN];}
      // else if Google's language URL variable is set (we will have to rely on it while using the search module)
      // we use it  
      elseif(isset($_GET['language']) && preg_match('/^[a-z]{2}$/',$_GET['language']) && in_array($_GET['language'], $available_language_codes) ){$langf = $_GET['language'];}
      // else if a session language variable is set, we use it
      elseif(isset($_SESSION['C_LANG'])){$langf = $_SESSION['C_LANG'];}       
      // else we assign the default language we fetch a little earlier
      else{$langf = trim($dlang);}  
      // and define a CURRENT_LANG constant to assign it whatever value we have just fetched 
      define("CURRENT_LANG",$langf);
  
      // we create a language session variable, that will help in cases when a language was selected other than the default one and the user/visitor reloads the home link with no parameter, so the current language is not set back to default.
      $_SESSION['C_LANG'] = $langf;

So, here we first take care off PLINK - if it wasn't set, we use the default value found in config.php (DEFAULT_PLINK), assign what we have to CURRENT_PLINK, that we create.

We do just the same for RLINK, except we will confront it to a menu type list found in config.php under the name of MENU_TYPE_LIST and which contains all the valid module names in use on the front-end part. If a module is set in the URL and can be found in the menu list, we then assign it to $rlink. Otherwise $rlink takes the default rlink constant value, DEFAULT_RLINK. We again create a constant to hold that value, which we name CURRENT_RLINK.

LocModel, also Singleton, is a very useful class that contains a few methods that will help us manage languages effectively. We will be using it here to fetch all the available languages.

We then fetch the default language and store it into $dlang and we then also fetch a list of our available languages, which we process to a new array called $available_language_codes.

Now, if a language was set in the URL and is found valid, by format and reference to our existing language list, we do use it.

Else, if a Google-owned language URL parameter is set (namely $_GET['language']), we will use it instead. This will happen only when using the search module (powered by Goggle CSE), while in two-column view.

Else again, if we have a language session variable set, we make use of it, otherwise, and only otherwise, we try the default language that we have fetched a little earlier

In any case, passed that point, we do have a valid module name, page name (empty or not), and language name, so that, we can route the proper translation files, using a try/catch bloc as follows :

 /* routing translations now */  
      try{  
           $ln_file = PATH_TO_LANGUAGES.'/'.CURRENT_LANG.'/'.CURRENT_LANG.'.php';  
           if (file_exists($ln_file)){include ($ln_file);} // if our language file exists, we include it  
    //otherwise we throw and exception
           else {throw new Exception('<p>&nbsp;</p><p>&nbsp;</p><div class="loading_langfile_fails"><u>' .$_GET[LN].'.php </u> cannot be found</div>');} 
      }  
      catch(Exception $e){  
           echo $e->getMessage(); //which we catch and echo here  
           exit(0);  
      }

This snippet is pretty much self explanatory. If the language file we are trying to include exists, we do include it, otherwise we throw and exception containing whatever error message we need to display.

And then we pull our current theme from the database

 //we first define our query  
      $q_tpl = "SELECT id_frontend_settings, frontend_settings_name, frontend_settings_value   
                FROM frontend_settings   
                WHERE frontend_settings_name = 'theme'  
           ";  
      MySQLModel::get_mysql_instance()->executeQuery($q_tpl); //we call on our MySQLModel to execute this query  
      if($myrows = MySQLModel::get_mysql_instance()->getRows($q_tpl)){ //if a result is found  
           define("CURRENT_THEME",$myrows['frontend_settings_value']); //we define a constant named CURRENT_THEME and we assign it the value the extract from the returned result  
      }

We simply store our freshly-pulled theme name in the constant named CURRENT_THEME, which we will use throughout the CMS wherever necessary.

And now time to take care off the user wanting to log out

 $auth = AuthModel::getInstance(); we instantiate our Singleton authentification class  
      if(isset($_SESSION['c_login']) && isset($_SESSION['c_pwd'])){ if the user is logged in and wanting to log out, we invoke our let_out() method from the Authmodel class  
           if(isset($_GET[LETOUT]) && $_GET[LETOUT] == 'yes'){  
                $auth->let_out($_SESSION['c_login'],$_SESSION['c_pwd']);  
           }  
           if(preg_match('/\/out/',$_SERVER['REQUEST_URI'])){  
                $auth->let_out($_SESSION['c_login'],$_SESSION['c_pwd']);  
           }  
      }

We store an instance of the AuthModel class in the variable named $auth. Then if the user is logged in and wanting to log out, we call the let_out() method, which will perform the logging out itself.

Then comes somehow the most important call of our index file, the call to the router's route() method.

This is exactly where we go deeper in trying to understand the core mechanisms that will make a module load upon being requested via the URL, be it a module to handle the serving of content, a module to allow the user to sign in or a module to manage some options in the back-end, it all loads from one object only - the router object.

In fact, back to design patterns, the very pattern that we will encounter now is called the factory pattern.

The factory pattern maybe be defined as a pattern in which the factory object creates other objects. This has a number of obvious benefits, such as the centralizing of the process of creating new objects. Therefore, if you need to change anything to the way you create and instantiate your new objects, then you only have to do so inside the factory.

In our case, the factory is our router. Our router, based on automatic URL parsing, will programmatically instantiate the controller of the module the client/user has asked for, and set it to work it by calling its initialize() method.

Just like with a regular factory. The client company needs a product, sends an order form, the order being our URL, the marketing people take the order form and tear down only the relevant page where the needed product is described, and handle it to the main plant people which in turn create the product and initialize it.

The __construct() method of our router class would be the order handling department, and the route method() would be the product building plant, in which is passed, as a parameter, the registry object we have created earlier, to be passed on, as a parameter again, to the controllers while being instantiated.

The registry works much as a stocking unit or a phone directory if you prefer, in the sense that you can store objects in it, to be later pulled out whenever required. How is that done? by using magic set() and get() methods, that will be triggered internally every time we will try to write/read to/from inaccessible properties, instead of having PHP generate an error.

 <?php  
      // application/Registry.php  
      class Registry{   

           private $vars = array(); //we declare the vars array as private  

           public function __set($index, $value){ we declare the magic __set() method, triggered when trying to write inaccessable properties  
                $this->vars[$index] = $value; // we store in the array the index associated with its value  
           }  

           public function __get($index){ we declare the magic __get() method, triggered when trying to access inaccessable properties  
                return $this->vars[$index]; //we return the value of a given index contained in the array  
           }  
      }  
      ?>

In our __set() method, which is run when writing data to inaccessible properties and which accepts an index/value pair, we simply store the index in the private array named $vars, which is the stocking unit or phone directory really, and we store its value altogether.

In the __get() method, which is run when accessing data to from inaccessible properties, we simply return the value of a given array vars index by passing it as a parameter.

But back to our Router class

 <?php  
 class Router{
  
      private $path, $controller, $action;  //declaring the private properties we need

      public function __construct(){  //initializing our router object for when instantiated

           $exp_menu_type_list = explode(";", MENU_TYPE_LIST);  //we fetch and explode our menu type list again, we will need it here too

           if(isset($_GET[RLINK])){  //if a module name is set in the URL

                if(     CLEAN_URLS == true   // if clean URLs are on and google search is active and in two-column view mode
                     && GOOGLE_CSE_PAGING_TYPE == 'two_column'        
                     && preg_match('/cx=(.*)&gs=(.*)&sa.x=(.*)&sa.y=(.*)/', $_SERVER['REQUEST_URI']))  
                {$request = 'search';}  // we set our current module name as search, wich we store in the $request variable
                else{  //otherwise
   // if the set module name can be traced in our existing module type list
                     if(in_array($_GET[RLINK], $exp_menu_type_list)){$request = $_GET[RLINK];}  // we assign that name to $request
                     else{ 
                          // otherwise we use the DEFAULT_RLINK constant value  
                          $request = DEFAULT_RLINK;  
                     }  
                }       
           }  
           else{$request = DEFAULT_RLINK;} //// otherwise we use the DEFAULT_RLINK constant value 

           $this->controller = !empty($request) ? ucfirst($request) : 'Index';  // if $request is not empty, we assign its value (with the first letter made uppercase) to the controller property, otherwise, we assign it the value 'Index'
           $this->action = 'initialize';  // we set the action property to 'initialize'
      }  

      public function route($registry){ // our factory's building plant  

                require_once('application/BaseController.php'); we include our abstract controller class from which every created controller will extend  

                $file = 'application/controllers/' . $this->controller . 'Controller.php'; // we build the full controller's class path using the retrieve URL module variable retrieved in the __construct() method  

                if(is_readable($file)){ // if the controller class is readable,  
                     include $file; //we do include it  
                     $class = $this->controller . 'Controller'; //and set the $class variable  
                }  
                else{  
                     include 'application/controllers/Error404Controller.php'; //otherwise we include the 404error class  
                     $class = 'Error404Controller'; //and set the $class to that  
                }  

                $controller = new $class($registry); //whatever the included controller, we instantiate it, creating the $controller object, passing our $registry object as parameter, itself containing our template object.  

                if (is_callable(array($controller, $this->action))){ //if within the newly created $controller object there's an initialize() method (demanded by the baseController) that's callable   
                     $action = $this->action;  
                }  

                $controller->$action(); we do invoke that initialize() method we have called above 
      }  
 }

We first need to pay attention to its __constructor() method, in which we retrieve our URL module variable ($_GET[RLINK]) (the page we tore down from the order form), assign it, after checking it corresponds to a valid module name, to the $controller property, otherwise we assign it the value 'Index'. If google CSE is active in two-column view mode and with clean URLs on, we assign 'search' to the $controller property.

Now onto the route() method, we bring our last core class, the base class, by including an abstract baseController class inside the router. The soon-to-be instantiated controller class will extend that BaseController class, so that it will inherit from its protected registry property, however, we as programmers will be free to decide how we want to implement the initialize() method that baseController is imposing on us. Note that as an abstract class, BaseController cannot be instantiated.

 <?php  
      // application/BaseController.php  
      abstract class BaseController{  
           protected $registry; //holds a protected reference of the registry  
           function __construct($registry){  
                $this->registry = $registry; //sets the registry  
           }  
           abstract function initialize(); //forces each sub-class to have an initialize() method   
      }  
      ?>

But back to the route() method, if the router then finds our controller file to be readable, it includes it, otherwise it includes the Error404Controller class.

Whatever it has included, it instantiates. So now we have a controller object ready.

Further on, if that controller object's initialize() method is found callable, our router will call it. The initialize() method is where we will define the actions we want each controller to execute for itself and have it write some properties to the registry's template object to be passed directly to the corresponding view, in order to be used there. Within that method, we will also have each controller call the assign_theme() method of the registry's template object it holds.

This is how our user input is being routed. But then, we have to find and instantiate the model that corresponds to each created controller too. Because the models are the essential component that will provide our application with the business logic and data it needs. So, this is where the magic __autoload() function comes handy

 function __autoload($class_name){   
           //The $class_name parameter is internal to PHP, so we don't have to set it ourselves.   
           //In fact, this will be set for us when the controller will first call the model it needs but the model will still not be included though.   
           //That will trigger the __autoload() function, in which we specify where to look to find the needed model and include it.  
           try{  
                $filename = $class_name.'.php';  
                $file = 'application/models/' . $filename; //but we make sure the __autoload() function performs its search within our model directory only  
                if (file_exists($file)){include ($file);} // if the class can be found, where we have told the __autoload() function to look for, it includes it  
                else { //otherswise throws and expception  
                          throw new Exception('<p>&nbsp;</p><p>&nbsp;</p><div class="loading_model_fails">'.$GLOBALS['t_the_model_named'].' <u>' . $class_name . '</u> '.$GLOBALS['t_couldnt_be_found'].'</div>');   
                          // note the use of globals for handling the translations, we will come back to that in the next settlements  
                }  
           }  
           catch(Exception $e){  
                echo $e->getMessage();  
                exit(0);  
           }  
      }

Did I say magic? Yes, it is a magic function, just as __set() and __get() are too. It will be called each time a called model class will not be recognized. So, it really is magic because, we do not know in advance which controller is going to be triggered. So, instead of having to include all our model classes, we only need to let PHP do the work of 'not recognizing' the model class the then-working controller object is trying to instantiate, call and instantiate it for us. Awesome, isn't it?

But what of the view then? As we said earlier, the view files, which are in fact basic php files acting as templates, will be included by the template object's assign_theme() method, itself called in the controller's initialize() method.

 <?php  
      // application/Template.php  
      class Template{  
           private $vars = array(); //declaring the array that will store the variables to be passed to the view  
           public function __set($index, $value){  
                     //magically assigning index/pairs to that array  
               $this->vars[$index] = $value;   
            }  
            public function assign_theme(){   
                //the method the controller calls once it has finished   
                //interacting with the model and wants to display the view  
                try{  
                          //We loop thru the vars array containing the variables the __set() method above has stored  
                                    foreach ($this->vars as $key => $value){  
                                         $$key = $value;  
                                         //we turn each key name to a variable using the $$ syntax, assigning it the same value it already held before entering the loop.  
                                    }  
                          $common_template_files = array('header','main','footer'); // in reality, we do not display only one php view file per/module,   
                          //as for obvious abstraction or visual design reasons, we choose to arbitrarily include the header, main and footer php view file,   
                          //and we will include [module_name].php view file only from within the main view file,   
                          //if the module_name variable has been sent by the controller  
                          foreach($common_template_files as $ctf){ //for each common tpl files  
                               $file = PATH_TO_THEMES.'/'.CURRENT_THEME.'/'.$ctf.'.php';  
                               //we build its full path  
                               if (!file_exists($file)){ //if the common tpl file does not exist  
                                    throw new Exception('<p>&nbsp;</p><p>&nbsp;</p><div class="loading_tpl_fails"><u>'.$ctf.'</u> '.$GLOBALS['t_couldnt_be_found'].'</div>');  
                                    // we throw an exception  
                               }       
                               else{  
                                    include($file); //but if it does exist, we include it  
                               }  
                          }  
                     }  
                     catch(Exception $e){  
                          echo $e->getMessage();  
                          exit(0);  
                     }  
                }  
           }  
      ?>

Note from the code above that we don't actually display only one php view file per/module, as for obvious abstraction or visual design reasons, we choose to arbitrarily include the header, main and footer view file instead and we will include the [module_name].php view file only from within the main view file called main.php, if the module_name variable has been set and sent by the controller.

So here, in essence, we already have a full-blown MVC application in our hands. A router (factory) that loads the needed controller based on user input, a magically loaded model to provide, through its own set of properties and methods, for all the logic and data our application requires and a view file, fed by the template engine, itself containing a magic set() method and being contained in the registry object that was passed on to the controller as a parameter while being instantiated and that includes, at the controller's request, all the views needed for display, plus, that also stores, by means of set() methods, and displays all the data the controller wishes to handle to the view.

In the next settlement, we will set the focus on the controller, the model and the view, on how they are built, work together and we will come full circle by creating our first complete module, the page module. Do not miss it!

This article first appeared on Tuesday the 28th of October 2014 on RolandC.net.

How to build your own Multilingual PHP MVC CMS from scratch - Part 1 - Introduction

noreply@blogger.com (rolandc.net) — Thu, 23 Oct 2014 03:33:00 +0000

While the MVC architecture has been around for quite a long time, it somehow took longer for PHP than for other languages like C++ to come to embrace it, allowing it to serve as solid ground in a growing number of popular CMS's and Frameworks. But even if nowadays the number of Web developers that can truly claim they have never heard of CMS's like Drupal or OpenCart is becoming increasingly seldom, you, as a programmer, may have often been wondering, as I once have too, just how does the CMS your Project Manager has assigned you on really works, so you could start making the most out of it and stop having to loose half your evenings, week-ends and personal life just to barely keep up with or learn it, let alone the personal stigma that not getting along too well with a custom in-house CMS may at times create in a developer's life.
Since the best way to understand how a device works is by creating one yourself, in this beginning twelve-part series, I will be teaching you how to build a complete and working lightweight Multilingual MVC PHP5 CMS from scratch, that you will be able to use for your own purposes or that will at least leave you with a better insight on how those things really work, get you more pro-efficient. And we will only be using free software tools throughout the whole course of these series.
But during this very first part, and once I have discussed the minimum knowledge required to attend these tutorials, i will be defining what the acronyms CMS and MVC stand for, then I will be reviewing the reasons as to why building your own CMS should only be an exciting, rewarding and beneficial experience. I will also be listing the software you will need and finally, I will expose and explain the basic folder structure around which we will be developing our new project.

Target audience

Although being a senior PHP developer is definitely not mandatory here (especially that after all, we all have to learn things before we can claim we know them), you should at least be confident with the use of classes and of some of the most common practices/algorithms in PHP/Web development, so that, you should not be a total beginner. This however does not mean beginners are not welcome, on the contrary they are, as beginners, always encouraged to read code, especially code they cannot figure out, for their own benefit.
You should have a fair understanding of what Object Oriented Programming means, and ideally of software design patterns, but this is not essential for now, as it will be discussed later in the series. You should also have a strong interest and the time required to build a complete CMS from scratch of course.

So, what does CMS stand for and what is it used for anyway?

For you to properly understand what a CMS is, I will first define what a Framework is and what the difference between the two actually is. In Web development, a Framework, hear a Web Framework or Web Application Framework, is a collection of files and folders (software) arranged according a specific structure or architecture and in such a way as to allow, to a certain degree of abstraction, for the quick/rapid development of Web applications (most commonly Websites) and which aim is basically to reduce the overhead traditionally associated with Web development. In other words, a Web Framework can mostly be seen as some sort of abstract software that would allow someone building a complete full-fledged site ready for production and in the least possible development time. For the sake of this tutorial, this is the definition we are going to stick with for now.

How does a CMS compare to a Web Framework then?

A Content Management System, or Web CMS in this context, simply put, is a Web application (most commonly a Website), that could have been built on top of a Web Framework, or not, but that is designed and optimized to help manage content easily and that ideally provides a certain level of customization capability, as, a CMS like for example Drupal, should be manageable/customizable by a non programmer, eg: the admin of the site can add/edit new articles, change theme etc., without having to know about its underlying structure. So a CMS, in essence, offers an extra layer to what a Framework usually provides, and can be viewed as a ready-made Website/Web application that can be deployed as is. Now for some more advanced customization, programming knowledge may be required.
So, while CakePHP is a Framework (by the definition we have used at the beginning) that could well serve as the basis for developing your own CMS, that is, depending on what your needs as a developer are anyway, it does not, by essence, offer out-of-the-box content-management oriented functionality like Drupal for example does and can only be interacted with by a programmer.
Now, it tends to get complicated when you know Drupal is called either a CMS, a Framework or Web Framework or even Web Application Framework (WAF), when you know that CakePHP is a rapid development Framework(as explained above) but that the company's built-in CMS you may be struggling with all day and that was created out of mostly popular CMS's parts is called a Framework too by everyone in the company you work for.
Frankly, most people's definition of a Framework/CMS nowadays is that it's some software/script that's to some level of abstraction is meant to ease/speed up the process of developing/creating a Web site or Web project, and it's still true in its own right.
Finally, popular CMS provide many functionality you don't necessarily need or use, and that are likely to increase the risk of bugs, vulnerabilities and so forth. While with a more abstract Framework like CakePHP, you do not have to build feature you don't need.

And what about MVC in all that?

MVC, which has been around for some time with languages other than PHP, and which stands for Model View Controller, is a type of software architecture that is designed to clearly separate an application(a Web application here) into three distinct parts: the control, the model and the view. The way we will implement it in our project, basically, the controller receives an input (via the index file) from the mouse or the keyboard for example, addresses the corresponding model in order to get the needed data and/or to process it according to the business logic contained in the given model, which then sends it back to the controller. Then the controller transmits that data to the view, which is responsible for managing visual display on the application, thus, how the site or app looks like. In other words, the controller will act as an interface between the model and the view, allowing for a clear logical separation between those processes, and most evidently for a cleaner PHP code, not being obfuscated by HTML or inline CSS snippets. Now, as the MVC pattern itself however does not define how the data should be passed between entities, it is therefore possible to find Web applications that use this architecture in a different way, having for example the model updating the view.
Regardless of how it is being used, such an architecture represents an evolved way to design an application and differs from the three-tier organization model, somehow very close in essence but where applications are structured around three layers: the client(presentation), the application(logic), and data access(database). That said, MVC is meant to make both the programmers and designers life easier, as, the designer can concentrate on working on the visual aspect of the project, generally through template files, while the programmer takes care of the business logic, eg: PHP code found in models. The controller of a PHP-driven CMS contains PHP but does not hold, or should not hold any element of your business logic.
Now that we have explored the main concepts around which we will be developing our application, a little word again on what we will exactly be building during these twelve-part series. We are going to build a simple lightweight Multilingual CMS that follows the MVC pattern and that will act as finished Website, ready to be deployed and administered by non-programmers. Customizing it for various other small-scale projects should only require little programming knowledge, if any at all. It should be perfect for a small-scale organization.

Fine, but why building your own CMS anyway?

Let's face it, creating your own CMS does require a lot of spare time, BUT

as a hobbyist, it is a great way to learn about the inner workings of CMS's and to learn about the MVC structure, which is growing enormously in popularity
as a PHP professional working inside a company, it will help you better cope with the company's custom-built CMS you already work on daily, if you do.
as a PHP professional working independently and looking to get things further, it will help you create the custom CMS you perhaps have always dreamed of, tailored to almost instantly meet your most recurrent client prerequisites, but best of all, that you will fully know and understand, thus allowing you to cut down on development time dramatically, leaving you more time to focus on other aspects of your activity.
There are lots of great free popular CMS's on the market, that some developers even specialize in customizing, but for the others, wasting hours looking to solve problems that you can't put your finger on just because you haven't coded it yourself and there is simply too much data to deal with - is never that fun, and gives you one more excellent reason to give it a go and see for yourself how much you could benefit from building your own CMS build from scratch.

Now, before we start getting our hands all greased up, let's review the tools you will need to to be working with:

Your favorite programming editor.
PHP 5 (with GD and jpg support enabled) - version 5.4 to 5.6 should be fine.
Apache HTTPd server 2.4, version 2.2 should be fine too.
MySQL Community Servers version 5.5 or 5.6 are good choices for our project.
An image editing program: I will be using the Gimp 2.8, but you could still be using Photoshop or alike if you prefer.
Optional (although strongly recommended) :
- A debugger like XDebug and a tracer such as Valgrind.
- Composer to help you manage our plugins (PHPMailer/TinyMCE) dynamically.

Basic overview of our project's folder structure

So let's take a brief look at what our overall folder structure is going to look like

Our project's general folder structure

From the image above, you can see the admin section has its own standalone folder.
Config.php will be our config file for the whole project, and serve for the admin as well. Some settings do rely on the database but most of the configuration will be found in config.php though, including database access parameters.
The /application folder, as it exists in /admin too, contains our controller and model files. It is the core part of our application, thus the name application. It also contains our base controller, registry, router and template engine, which we will review in the next part of our tutorial, while studying the index.php file.
The /languages folder will hold the needed translation files, country flags and everything needed to manage encoding as well as Javascript translation strings, all on a per-language basis.
In /vendors we will simply store the plugin files needed for our project. In fact, composer will store them for us, as we will only have to pull new versions of our plugins from the command line, whenever needed. The plugins we will use are TinyMCE 4 (Wysiwyg editor) and PHPMailer 5.2.6.
The /public folder will contain our Javascript files.
In /themes, we will store all the CSS files, template files and site images(site's visual identity) pertaining to each existing theme.
At root level, we also find the index.php file, which actually is, or should be, the one and only entry point to our application, as all user requests should reach the index first, or be redirected to it, no matter what.
about.php, provided you launch it manually, will check your server configuration, and more specifically, it will check your Apache/PHP/MySQL versions, as well as your GD library version, and if you happen to have support for JPEG (used for the captcha image in the registration form).
The /list folder will contain lists like country or language lists and the tools to dynamically manage them.
The files named composer.json and composer.lock are inherent to Composer. They contain data necessary to manage our plugins. Again, we will only have to use the command line to pull in the updated plugin files whenever available.
The second multi-level screen capture stops at the beginning of the vendor folder because there only remains the content structure of our plugins, which will will not take interest in.

To help you understand the structure better, here is a multi-level folder representation of the same project, without the files.

Multi-level view 1/2

Multi-level view 2/2

As you can clearly see, the files and folders that are inside the /admin folder repeat almost exactly the same folder structure as we have just reviewed. The admin in itself will be like some sort of modified front-end within the front end.
So far, we have discussed who the minimum knowledge requirements for this tutorial, defined what the acronyms CMS and MVC mean and explained what differentiates a Web CMS from a Web Framework. We have also reviewed the reasons as to why choosing to build your own MVC CMS can be a very exciting and rewarding decision to make for yourself, before enumerating the tools we need to get started, and ultimately engaged in reviewing the core folder structure of our project. In the next chapter, I will be focusing on what I have called earlier the one and only entry point to our application, that is the index.php file, slowly evolving toward the /application folder, which represents the core system of our CMS, containing all the controller/model classes that will empower the MVC structure in our project.

This article first appeared on Thursday the 23rd of October 2014 on RolandC.net.

Linux must-have essential software 2014

noreply@blogger.com (rolandc.net) — Wed, 22 Oct 2014 06:06:00 +0000

Whether you're being new to the world of Linux or not, at one point or another, you're going to periodically re-question the software that's already installed on your station.
As a beginner user, you will be haunted by the quest of ever trying to find new alternatives or best, to find copycats of the programs you used to have on... you know. But once you have gained significant experience, you will love digging the net for even more of that great software you already have and use, that is, not just to kill time though.
So here is my 2014 list of all Linux software I believe all of us (or almost) should have, hoping this will help you achieve even more and meet greater challenges through your PC, at least complement your current installation.

Tux trying to figure out the software he needs on RolandC.net

How to prepare Ukrainian Derunys

noreply@blogger.com (rolandc.net) — Wed, 06 Aug 2014 08:38:00 +0000

So you have been watching the news lately, saw every bit of that Ukrainian crisis and started wondering how the Ukrainian Cuisine tasted like? Well here it is, today I'm going to show you how to prepare Ukrainian derunys, genuine Ukrainian Derunys and I am going to show you just how easy (and cheap) it is to make them.

A plate of freshly prepared Ukrainian Derunys

Deruny(s), in Ukrainian (called Dranyky in Russian), are delicious fried shred-potato doughnuts that are extremely easy to prepare. They are eaten daily throughout the whole Ukrainian territory, and not only. Somehow, they are like Hash browns, the main difference being that, once the potatoes are shred, you do not need to drain their water. They are extremely similar to the Czech Bramboraky, the word bramborak itself meaning potato in Czech language.

Derunys taste delicious and not only they can be had as part of a breakfast or brunch (just like pancakes with eggs etc.), they can also be served either as a starter or main course meal, with mushroom sauce on it, or with a salad on the side.

Well, no more waiting, let's jump right into this awesome recipe!

The ingredients you will need :

- 4 small/medium potatoes
- 1 egg
- 1 tbsp all-purpose flour
- a fair pinch of salt
- 3 tbsp of oil
- a tiny pinch of bicarbonate (1/10 teaspoon)

Optional : a hearty tablespoon of smetana (sour cream or 'creme fraiche')

How to prepare derunys:

- Start by peeling the potatoes and shred them using the thinest side of your shredder. (You may also shred them using the medium side, this will feel easier for the hand, but the result will be different and it also will take longer to cook)

Freshly shredded potatoes

- Once the potatoes are shredded, do not wait, add the salt. This is what will make water from the potato shreds come out. Now, break the egg and add it.

Potato shreds with salt and egg waiting to be stirred

- Stir for less than a minute using a table spoon, but your dough should look homogenous enough already.

Deruny dough before adding the flour

- Add the flour to solidify the mixture and stir for a few seconds again. Now you want to be careful not to add too much flour, not to little either. As you add too much, your derunys will end up tasting like hockey pucks, and if you add to little, they will become too sloppy too. One fair tablespoon for 4 small/medium potatoes is probably a good rule to stick by in this case. In any case, the resulting mixture should look thicker than crepe dough.

- Put a pan/skillet on the stove, medium/high heat, with 3 hearty tablespoon of oil in it.

- Add the bicarbonate to the mixture. Be careful adding only a 'tiny' pinch of it. Using the tip of a knife to pick it up from its package is probably the best way to go here. You may pour the bicarbonate into a tablespoon first and add a little water to to dilute it if you wish. This can especially come in handy if you had poured too much flour in the first place. Stir again for a few seconds. At this point, your mixture looks very smooth.

Deruny dough after adding the flour and bicarbonate and stirring

- As the oil in your pan has become quite/very hot, pick a whole tablespoon of your mixture and pour it into the pan. Do not worry about having to shape the derunys while they cook because they will do that on their own, naturally. Repeat this step until your pan is full. Make sure also, as the derunys start cooking, that they don't stand too close one from another. Once they have been cooking for some time, they will be able to touch without sticking, but not at the beginning though.

- You can leave the heat quite strong while laying down the mixture into the pan, but once that is done, to avoid burning your derunys, reduce the heat by half at least. Wait a minute or two, and once each of the derunys has its bottom brown/golden (though not burned), flip them all using a fork. Start with those who were laid first.

Derunys starting to fry

- Once all the derunys have all been flipped, make sure the heat is kept gentle enough, and slowly cook for 3-4 minutes, again, not trying to burn them, but it also has to cook well on the inside. We don't want to end up eating raw potato doughnuts, do we?

Derunys as they just got flipped, ready to cook longer on lower heat

- If you end up having more mixture in your hands than the pan can contain, you then have two choices: either you don't have that much mixture left and you sort of manage to add more onto those frying already (that is if you haven't flipped sides already), or, you make another round, clearing the pan first and adding some oil again, etc.

- Once ready, lay out the derunys on a clean plate, put a cover on top only if you wish them to become more tender/sloppy/mellow, and ultimately if you wish to retain their heat too.

Cultural note: In Ukraine, derunys are originally a traditional dish and they tend to be served with some fresh Smetana on the side, usually a whole tablespoon of it. They can also be served with mushroom sauce on top. As part of a traditional event, they are usually part of a larger table containing various traditional dishes.

This is the perfect example of recipe that's amazingly easy to master and you will soon be able to prepare derunys in the morning faster than you would prepare scrambled eggs.

Smachnoho! (pronounced SMACH-noho : Ukrainian for bon appétit)

Stay tuned for more on RolandC.net!

This article first appeared on Wednesday the 6th of August 2014 on RolandC.net.

12 tips to increase your smartphone's battery life

noreply@blogger.com (rolandc.net) — Tue, 05 Aug 2014 06:43:00 +0000

When I got my first smartphone, I literally felt shocked at how frequently I had to plug it to the charger, shocked by what I had come to believe was the result of an abnormally poor battery standby capacity. I could not understand why was it that... if my old phone of the same brand could easily last a whole week without having to be recharged, why would it be that this one, a newer one, ten times more sophisticated in every aspect, had to be plugged to the wall at least once a day or more - wrong it felt, and it felt like I had hit a defect - and I could already see myself screaming at some maintenance staff on that I had just bought that phone and that there was something wrong with its battery that needed to be replaced and so on.... STOP.

A phone's charger and its battery

From the Dutch Hutspot to the Perfect Brunch : Let me introduce you to the BrunchPot!

noreply@blogger.com (rolandc.net) — Mon, 04 Aug 2014 09:50:00 +0000

Feeling tired of having the same breaky over and over? Needing to change your food habits?

The Hutspot is a delicious yet full-filling Dutch mashed-potato dish that dates back to the 16th Century and that primarily contains mashed-potato/carrot, onions, and that may contain meat like beef, or pork a sausage.

A typical BrunchPot served with a sliced cucumber on the side

Hutspot is being cooked in the Netherlands down to the Flandres in the North-East of France, and the way it's being prepared, its name as well as the used ingredients may vary from one place to another.
More »

How to change Google Custom Search Engine title font size in page result

noreply@blogger.com (rolandc.net) — Mon, 14 Jul 2014 08:35:00 +0000

A quick tip today for those who have been banging their head trying unsuccesfully to modify the font size of the title in their Google CSE result page :

 .gs-webResult.gs-result a.gs-title:link, .gs-webResult.gs-result a.gs-title:link b, .gs-imageResult a.gs-title:link, .gs-imageResult a.gs-title:link b {  
      font-size: 12px;  
 }

That's it, enjoy, and stay tuned for more on RolandC.net!

10 tips/questions you should definitely consider before buying your first smartphone

noreply@blogger.com (rolandc.net) — Fri, 31 Jan 2014 15:56:00 +0000

If you have never owned a smartphone before, but are looking to buy one and feel unsure as to what product to buy exactly and at which price - look no further - here is a list of 10 tips/questions you should definitely consider in order to ensure you get the smartphone that provides you with all the functionality you need and offer you the best value for your purchase.

Question #1(the obvious): Do I really need a smartphone and can't I just do away with my current phone, laptop and/or netbook?

I mean, are you really sure just exactly what kind of features or functionality you need and for which you are going to be spending your hard-earned money ? Are you really sure they will not overlap those your current laptop/netbook already offer and that they will definitely help you improve your activity and/or well-being ? That you are just not buying some expensive tech gadget because others already have it? Weigh first the pros and cons and ask yourself honestly whether you really need one or not.

Question #2: iOS or Android or...?

While both are meant to more or less serve the same purpose, achieve roughly the same results, at least from a beginner user point of view, iOS is a proprietary system designed by Apple Inc to be used in... what was originally called iDevices, therefore iPhones, Ipad, etc., while Android is an open-source Operating System designed by Android Inc (later bought by Google) to work with...many phone brands.
Some argue that Android is great for tinkering with your smartphone but that if you need something that actually works, then consider getting an iPhone. Personally, I am the owner of an Android phone which works perfectly, gives me the results I have been expecting all along and I can confidently say I am totally happy with it.
Now, if we have to make a simple but technical comparison, iPhones would be like Macintosh computers and Android phones would be like Linux stations, as Android is linux-based, but the difference being that you do not need Linux knowledge to be able to use an Android phone. In fact, you do not even need to know anything. Windows users do fine on Android.
Other systems exist too, like Blackberry, but it's your first smartphone and we want to make it simple, don't we?
But the bottom line being that you should not expect to be able to buy the latest iPhone for less than 500 euros, if brand new and not counterfeit. This while you can definitely get a descent entry-range smartphone with Android 4.1 on it for less than a hundred euros.
Last but not least - the apps you will be likely to download for your smartphone, most of them will be completely free and available directly from Google Play Store, while you will hardly find free apps in the Apple's AppStore, which holds apps for devices running iOS. Choice is your alone.

Question #3: Does size matter?

Looking back at the time before I actually went on buying my first smartphone and although I had researched the internet for clever advice on what criteria to take into consideration, I still wasn't sure my thin fingers wouldn't betray me on my future keyboard, would allow me to type a simple sentence in less than half an hour. And as i began to research that topic more consistently, it became clear that in the ever-growing smartphone world, fat-fingering really was an issue. And I started wondering - what if it turns out i can read emails, but can barely type to reply to them, what if I should have gone for a bigger model?
Well, as it turned out, and even though it's true my fingers do look thin, from day one I have never had any issue getting along with the typing part. I probably fat-finger once in a while but not more than I usually do while using my standard laptop's keyboard. So basically, to have a problem with the size of your smartphone, you would have to have really big hands with huge fingers, trying to use them on the smallest smartphones you could buy nowadays. Meaning generally that, if you have average hands, screen size should definitely not matter.
Passed the size of your fingers, it seems there's a trend going on nowadays to buy the largest smartphone just because it looks more expensive or somehow more powerful, but this is a tendency that is balanced by the sense taboo most of us can feel while holding a device the size of a tablet almost, by their ear, talking to it. It is entirely up to you though to decide whether you really need a device of that size or not. No one will blame you if you do.

Question #4: What kind of protection will I need to buy for my smartphone?

Good question. The answer starts with...what kind of user are you? And also, do you happen to have moist hands?
Your new smartphone will not be your old black & white telephone that only allowed you making/receiving calls and sending sms/mms. Your new smartphone is something that will - or should - impress you to the point that you will spend countless hours discovering new features on it, starting from when you still haven't even gotten out of bed yet, up until the podcast/mp3's you will be wanting to listen to before getting asleep. So there will be a lot of screen touching and device handling involved, probably to the point where you will realize...where you will realize you had never realized how greasy your fingers had always been.
For some, this is an issue that can be easily addressed by placing a thin vinyl/plastic foil on top of the screen so that your fingers never actually hit it directly. But the problem with that being that your screen then become less sensible and you end up having to hit harder to exercise the same amount of pressure. Another issue with that system being that, after some time, there seems to exist a whole glue-sphere effect going on between the foil and the screen, which is basically something one would store in the unpleasant effect category.
Now what if your new smartphone falls off the table? You need a case - that's right - you need a case, a hard one, that not only will keep the back and sides of your phone off your (potentially) greazy fingers, but that will also make for the strongest protection you could provide your new device with. What's more, you don't even have to get it in/out of its case every time you get a call or place one. Simply lift/remove the top part of the case, fold it back once you are done. So that no matter how many hours you will be spending on your smartphone each day, your fingers will essentially be in contact with the case only.

Question #5: Should I try the smartphone first before buying?

If you have that possibility then yes, go for it, as this could reinforce the legitimacy of your well-weighed choice, help you convince you have made the right choice, otherwise, you will already be on spot to try new models if necessary - but remember, being at the phone shop does not mean you should automatically come out with a brand new smartphone in your hands. This is a device you will probably spend a great deal of time with, so why not taking your time to carefully choose what you need?

Question #6: How much should I spend on my first smartphone?

That's an interesting question, to which I would reply - How much money would you spend for your first car? Would you buy a BMW while you just got your driving license?
Since you are (supposedly) only new to the smartphone world, the idea here is that it is probably best for you to buy an entry-range model, which should definitely meet all your expectations, and then, as you grow in knowledge and experience, you might consider buying a smartphone that has more advanced features.
On the other end, buying exactly the cheapest model might not be the wisest choice to make, as it might seriously lack in features, even or because of the price you will have paid.
Best in my opinion would be, let's say, if prices start a 60 euros and stop....say at 250 euros, best would be to perhaps choose a smartphone which price is in the range of between 80 and 120 euros.
Read reviews about the smartphone you are likely to buy, it should give you an overall idea as to whether other people would pick this brand/model for the same specific reasons you yourself would.

Question #7: Should I buy a smartphone while I'm on holidays in a foreign country?

Quite frankly, best would be to avoid doing that. Because some apps are actually restricting downloads to certain geographical zones. So, supposing you live in the U.K and you just came back from a holiday in India where you bought yourself a nice smartphone and want to try downloading the BBC's official iPlayer app right from Google Play Store (you have bought an Android phone) - but surprise - you get a message that actually tells you "this app is not available in your country".
Now, while it's possible to fake your phone's geographical location using proxies, this is probably not the way you wish to be using your first smartphone, because this process will automatically force you to install apps that will require rooting your phone and here we are talking about a process that, depending on how it's done, can seriously damage your phone, 'brick' it, which means leaving it as slow/dead as a brick, therefore totally unfit for normal use. It is however true that, a sometimes available workaround is to install the sought app directly using a package (.apk) but this not always being an available option.

Question #8: Should I buy an extended battery?

The one issue that puzzles new smarphone users, and that did puzzle me too at first, is battery longevity - or else - for how long can your smartphone stay operational before having to recharge its battery.
While most traditional phones can stay lit for a week or more, smartphones, it seems, have a hard time staying on for more than....two/three days in a row without needing a refill. I'd even go as far as saying that most new smartphone users cannot make it through the end of a single day without having to plug the battery cable in. And this is all for good reasons since a smartphone has so many extra energy-consuming features that standard GSM phone just do not have.
But deciding whether you need extended battery life or not will first depend on how you will use your smartphone, meaning, do you need to listen to mp3's all day, show your videos to your friends at school? Are you constantly on the road for your job? etc, etc.
It's worth mentioning that, although it seems as though using battery-saving apps is the wise thing to do, and there are a lot of them out there, doing so could also dramatically reduce your battery's life and performance.
As you gain knowledge and experience, you become better able to recharge less often, without having to rely on such energy-saving programs.

Question #9: Should I buy an extra memory card and if so, what kind should I buy?

Well this also depends on how you are going to be using your smartphone anyway.
If you buy it just to have a way to check your email while on the road, buying an extra card might not be that urgent or necessary. But if you decide after a while, once you have a good feel of what your purchase can do for you, that you do need an extra card, let's say to have a few movies ready for watching while in the train, then there are a few things you should consider, namely three. The type of memory card, its capacity and class.
For the memory type, meaning microSD, etc., you will need to read your manufacturer's manual or search Google for your phone's full specifications - this info should be available, that is, what exact kind of extra memory card will work on your smartphone.
Memory card sizes nowadays can be of 8, 16, 32, 64 gb and having used your smartphone for a few weeks already, you will definitely have a good feel of what capacity it is that you really need, although, your phone's specs should tell you up to how many gigs you can insert in the device. But in any case do compare prices, because it is likely that you find a 16 gb card that ends up being almost the same price as for a 32 gb, for the same brand, model and class.
All of which is leading us to discuss the meaning of memory card classes. So what is the class of a memory card? Simply put, it defines the read/write speed of your card. Classes range from 1 to 10 and you're absolutely better off with a 10 than with a 2. That is why you can find incredible promotions on some cards, because they are of class 2. The thing being that it is definitely worth spending more for class 10 already.
Last but not least, I find it is not worth spending more than a third of your phone's price on a memory card. Indeed, it does not really make sense, so for a smartphone bought at the end of 2013, it seems wise to either buy now a 32gb extra card, or wait a few months to buy a 64gb one, once the price has gone down a little and basically once that your card does not cost more than a third of the price you have paid for the main device itself.

Question #10: SD, HD or Full HD? What are those and which to choose?
SD stands Standard Definition, HD means High Definition and Full HD means well... Full High Definition. Those are terms that refer to the image quality/definition of your screen. The more pixels your screen definition has, the better the image, whether photo or video, but the higher the price would be too.
So even though you might be in a position where you can easily afford to buy a smartphone that offers FullHD resolution, the truth is, I find smartphones that have this feature way too expensive for now, at least in regard to the proportion of devices that come with only SD or HD resolution. All while SD devices offer great human-perceptible image quality anyway.
But chances are it probably won't be long until FullHD becomes the new SD and is available at fair prices, affordable by everyone.

In the meantime, I strongly hope this article will help you choose the smartphone that is right for you and that suits you best, comes with all the functionality you really need, all at an affordable price, offering you the best possible value.

How to securely and inexpensively send a credit card or other valuable documents abroad

noreply@blogger.com (rolandc.net) — Wed, 29 Jan 2014 12:57:00 +0000

Sometimes, you need to send someone - or be sent - a valuable document abroad without which you just cannot do, like a credit card for example.
But you cannot risk having the letter/parcel get lost or stolen, so you need a totally secured, guaranteed way to have that delivery made and you start thinking about costly services like FedEx or DHL, which, indeed are... costly services.
As an expatriate I have often had, at least several times, to have credit cards and important documents sent to me via postal services, and, don't get me wrong, I have no personal bias against companies like the ones I have quoted above, and those are great companies providing serious and professional services but they would turn out to be too expensive for me everytime i would need them. So, what did I do then?

Back a few years ago, I decided to google for advice on how to send a credit card the cheap way, meaning still securely, but without having to pay for a minimum of 60/80 euros per document, if not more.
And I sort of found a post written by someone who explained his trick was to hide the valuable good inside some piece of clothes and send it via ordinary postal service. This got me thinking.

As a well-travelled person, I have often had to cross foreign borders, standing in line for hours with strangers, having immigration officers peering at me to see if there was anything out of the ordinary that popped up in their mind while they were looking at me, studying my behaviour, as they studied everyone else's too.
I had also been temping for a day once, a long time ago at a Royal Mail sorting center and I knew a bit about how foreign parcels were processed, based on what type of county they came from.

So, it all sort of became very logical to me at some point that.... for a credit card to cross oceans and borders without drawing attention and risking getting stolen or anything, everything has to look 'normal', as after all, your letter or package, is going through the customs like you would yourself while on holidays to a foreign country. And for obvious reasons, it goes through a process of human appreciation, plus through some scanning device, like for someone's luggage at the airport. Noone wants to take risks with that there and who could blame them?. Frankly I do not.

So, since you need to send or get sent something for legitimate reasons, there is nothing wrong with using a little imagination and let's say, if we take the example of a credit card, prepare a relatively new cd-rom or dvd-rom from your least preffered artist (you got it as a gift but just did not find the courage to throw it away), attach your card on the inside like the cd-rom manufacturer would attach a valueless promotional card, add a Happy Birthday card beside, and you're done.
Such a method should definitely not draw neither human nor machine attention while your letter/parcel awaits at sorting centers, wherever those centers are and whoever is on duty when that happens.

Of course you need to send it as a registered letter with return receipt and it will cost more, but it will still cost you approximately eight or ten times less than if it had been via specialized/services, and you want to do that because even if somehow it feels that sending it the basic way could draw attention even less, you still want to use some kind of cheap but effective insurance against internal postal theft, which we all know happens, in every country, civilized and less civilized alike.
Having said that, don't go, unless you wish to, for any extra-value services that your local post office is likely to propose. You will not get a better service from those, especially if you send your letter/parcel to a country where they can't figure out your language. What you need is the most basic, cheapest option to register (with receipt) your letter to abroad, the only vital thing here being to register it and it should definitely cost you under 8 or 10 euros that's for a 20-50g sending.
The receipt option is something you definitely want to add because even if postal staff of the receiving country cannot decipher it or simply doesn't know what to do with it, this will secure your sending again internal theft while it still hasn't reached border, and offer some kind of protection once it has crossed border. Even if as a foreign postal staff who couldn't read English you can't read on it, it makes you less likely to try any funny move since you know it looks like a receipt... .

Needless to say too that you do not need to tell your local post office what you are going to send. Even if you are certain you can trust the staff there and you went to school with them, do not, ever ever tell them you are going to send something of that value, as your letter might not even make it to the next village or town.

Also, you might use some administrative documents that look like they are official and important, but important to you, boring for others, and tape the card on it using some tape. Like it would be a discount or corporate, insurance card.
But now what about things that are bigger, that take more room? Well the same logic applies, that...everything has to look normal. New clothes could be a good choice, the trick being that, you need to imagine the stuff going through scanning at the airport, to try and picture how it would all look like for a custom officer watching the surveillance monitor, and whose job is to spot everything that falls under the category 'not-ordinary' or 'not 1000% ordinary'.

You also need to picture the letter or package being opened manually for extra-checking. I mean, you don't want to send a pair of thick socks to your son that lives in Thailand while you live in Canada, and hide the card inside the socks. This would draw attention, and this is what you do not want - draw attention. Few people need thick socks in Thailand, but above all, what kind of relatives send socks to someone thousands miles away, and what kind of person is adventurous enough to go to Thailand but coward enough not to buy his/her own socks and needs a relative to send some for them?

That's what I am about, you need to think just as a border officer would, and you need to use your common sense, and everything will run smoothly, safely, as securely as with the most popular secure delivery companies, but without having to break the bank.

Safely root your Samsung GT-S6312

noreply@blogger.com (rolandc.net) — Mon, 06 Jan 2014 13:59:00 +0000

Today i will show you how to safely root your Samsung GT-S6312 smartphone, without 'bricking' it. Note that you can just as well 'unroot' your phone the same way.
Although what I am going to show you now is a very simple procedure that I have succesfully tested on my own Samsung GT-S6312 phone and that should probably also work on any Samsung phone that has Android on it, I still give no guarantee that it is what will happen if you try it on a different model/brand.
In any case, you try this at your own risk. What i am saying however is that, if you follow my advice and if you own the same phone as I do, everything should go great.

Also, i am assuming you understand what root is, and basically that you know exactly why you wish to root your own phone, that you have weighed the pros and cons and everything, right?.

Having rooted mine, i have not lost any app or personal file/data or whatever, but it's never a bad idea to backup, so I encourage you to do a backup in any case. Better be careful than sorry afterwards.

Okay so let's get started.

Samsung GT-S6312 Young Duos Deep Blue

Step 1 - You need to download a free app called Framaroot, the version I've found on the net was Framaroot-1.8.1.apk, that you can download safely from here. Note: Android forums are the closest thing to an android resource site you could find nowadays, probably because Android being very new, so don't panick.

Step 2 - Once you have donwloaded this app to your comp, your need to transfer it onto your phone and execute it, or execute it directly if you have downloaded it right from your phone. So, complete action using Package installer and click yes when asked if you want to install the app.

Step 3 - Open the app and you will see a dropdown menu where you can select either install SuperSU or Unroot, choose Install SuperSU if you want root your phone, choose Unroot if you want to unroot it, that's as simple as that.

Step 4 - Now select the first exploit presented to you bellow, should be called Aragorn, and if like me you get an error message that the exploit failed etc., choose the next one on the list. Actually i have only two exploits on the list, Aragorn and Gandalf, and Gandalf works without any issue, so that's what probably will work on your phone too, Gandalf. If everything goes great, clicking Gandalf will result in the display of the following : 'Sucess :) Super and su binary installed. You have to reboot your device'.

Step 5 - So now time to reboot your device and check if everything went smoothly. To do so, just go to Google Play and look for a free app called Root Checker. Install it, launch it, click on 'verify root access' and find out. If everything went well, you'll get a congratulation message in green saying 'Congratulations! This device has root access!'

Note : many tutorials advise to go first to Settings->Developper options etc.. to enable debugging, allow mock locations, but in my case this was not a necessary step, rooting worked perfectly witout have to switch on developper options.

That's it, that's all there is to it. Stick around for more!

How not to's - Choosing a Gmail address

noreply@blogger.com (rolandc.net) — Thu, 01 Aug 2013 17:34:00 +0000

The tip i'm about to share with you here might sound like it isn't a tip but believe me it is, and that very tip could help you avoid having to scratch your hair next time you'll want to quick-register on let's say a site like Yahoo.com, using your Gmail address...

Let's say you've created a new Gmail address a week ago and it's all fine. But now you're trying to connect toYahoo via your new Gmail addee, such connection procedure being a feature more and more sites tend to offer nowadays, giving users the opportunity to not having to waste 10 mns or more typing registration info by simply allowing them to import their Google or Facebook data.

Gmail logo

And then it happens, you're denied registration on the ground that, i quote: 'Your Gmail email address contains text string not allowed in Yahoo!'. You start copy-pasting the message to your Google search box as soon as it gets thrown at your face but it won't go, it simply won't go because there are no workarounds for this one. No workarounds other than using a different Gmail address or use your Facebook credentials (if any) or else going for the full registration spin process, which of course wasn't your idea at first.

Such situation happens simply because your Gmail address probably contains a dot between your first name and surname, or an underscore maybe, or any character that Google itself allows at registration time. But take my word for it, a dot is enough to make you wish you had known all this in time.

Chances are this should never happen to you now, now that you know ;).

Stay tuned for more on rolandc.net

Fancy some chocolate? No thanks, i've quit!

noreply@blogger.com (rolandc.net) — Wed, 31 Jul 2013 21:02:00 +0000

It sort of amazes me that i could spend a good 38 years of my life not knowing that chocolate actually contains caffeine. Yes, you've heard it, chocolate and all cocoa-related products do contain caffeine. I can already here you say 'hang on, i've never seen any chocolate product package stating there was caffeine in there!', that's right, there aren't, and this for a good reason: cocoa beans naturally contain caffeine, so that companies are not legally required to mention its presence, unlike Coca-Cola who has to print the word caffeine on its labels simply because the caffeine that's contained in a coke has been added, and failing to do so would be against the law.

Now, as to how much caffeine is contained in chocolate products, one good rule to stick to would be, the darker the chocolate product looks, the more caffeine it contains, but this isn't the only rule to be considered. Remember the Tomaco episode from the Simpson's? well, that's what industrially-injected-caffeine products reminded me of when i first heard about them. Nowadays you get caffeine-enhanced cereals, so basically even products that originally don't contain caffeine, can have caffeine added to them. But back to how much caffeine is 'contained in chocolate products', it would be safe to say it averages the levels found in decaffeinated coffee, yes, decaf contains caffeine, even though a lot less, probably 10 mg a cup while a black tea averages 60 mg. But the problem with decaf is the method used to decaf... . If done chemically, then chances are you're probably swallowing weird chemicals that harm your body even more then caffeine does, when you're having your cuppa. It is difficult to give a reliable comparison since people make tea differently. It's also true to say that the levels of caffeine contained in the cocoa beans vary according to the way the beans are roasted, the variety itself too. A Hershey bar, dark one, contains 60 mg, just like an average cup of tea does.

Cocoa products do contain a certain level of caffeine

Basically, if your doctor sets you on a caffeine-free diet, for whatever the reason, or if you've just decided to quit consuming stimulants because you wish to have a life that's way healthier, you won't completely be off the hook until you have said no to:

- coffee, decaf, tea, decaf tea and all related products
- chocolate and all cocoa related products
- all products to which caffeine is added industrially and belonging or not to the aforementioned categories
- and...said no for 5 days.

Indeed, caffeine is a drug, not a habit, it's a drug, and the physical withdrawal from it, in the most severe cases can take up to 5 days, only. The rest being psychological... . Upon quitting you will most likely experience headache symptoms, which then again, will vanish soon enough. But if you have no intent to quit consuming caffeine products, then this article would have still helped you get the facts, hopefully.

One vital fact about cocoa product consumption though is that, in 2013, about 75 % of the world cocoa consumption comes from the Congo, where enslaved kids make for forced overhead. Those kids are more or less deliberately abducted at the Burkinafaso border and sold for approximately 230 euros to local producers or whatever you will call them. Companies like Nestlé deny being engaged in such practices but... documentaries have been made already, containing hidden-cam footage, backed up info, this is the real price for chocolate, not just the price to your health.

Now you will say, chocolate contains anti-depressants that help me cope with things... . Wrong angle i say, because, consuming anti-depressant foods only contributes to raising the toxicity level in your body, beside addicting you to the anti-depressants contained in them anyway, and although you first get the impression you're better of living that way, it only adds up with everything else you usually have, only to affect your metabolism the wrong way, thru time and you end up gradually thinking, being convinced that you couldn't make it without your chocolate bar once in a while. But it's just like saying eating more will get you less depressed and than you will feel happy and start eat less... it just cannot work, at least for long enough.

One important debate is, can the levels of caffeine contains in decaf or in cacao make you addicted? Some scientist think that yes, while some don't and it's very difficult to come up with consistent data in those areas on the overall. From my experience, the problem with caffeine contained in chocolate is not its levels, especially if you do have coffee already on a daily basis, but rather the toxicity it brings to your body and ultimately to your brain, knowing that all addictions in the body respond to one and the same place in the brain, as much as we know nowadays. So that, in other words, consuming chocolate destabilizes your metabolism even more, the body not being even able to actually make a difference between the sensation caused by the withdrawal from caffeine (which happens as soon as you have stopped eating your chocolate or having your coffee and NOT when it's been two days you haven't had your coffee or chocolate bar) and the normal sensation of hunger for food.

Writing about the pros and cons of all caffeinated beverages and writing about addiction is beyond the scope of this article, but know that, if you seriously consider quitting caffeine then alternatives there are, such as Rooibos or Hibiscus infusions or simply a hot milk or a glass of water, depending on the season or where you live, there are always alternatives.

So, what is your relationship with cocoa-related products and are you one of those who feel they could never do without their afternoon chocolate bar or on the contrary are you already managed to escape the chocolate trap and prefer fruits or anything else as snacks?