PHP ob_start and Linux tee Primer Tutorial
Today we set up a performance timer for the use or not of the PHP ob_start() / ob_end_flush() buffering method duo (plus other related methods, as you will read from these links, and, later, below, hopefully).
Tests seem to show a slight improvement of performance (perhaps one second of showing 1200 tables as per the tutorial picture HTML table we use … you may remember this from PHP/Javascript JSON Feed or Array Data Primer Tutorial) using the ob_ methods, but the effect seems small, and we want to point out another use of the ob_ methods … any obs?! … chortle, chortle.
The other use of ob_get_contents() used before ob_end_flush() or ob_end_clean() is to use in conjunction with file_put_contents to write out a copy of your webpage, while it is in the process of being created. As we do today, because you have not done ob_end_flush() yet, you can even use ob_end_clean() then header() to redirect to this copied webpage (or use ob_end_flush() to proceed as normal).
So why is there mention of Linux tee command in the blog posting subject today?
Well, this all reminded me of the handiness of the Linux or unix command tee to pipe the contents of another Linux command to clobber another file, or use tee -a to append to another file.
With that in mind there is an option in today’s live run with the PHP downloadable programming source code you could call ob_tester.php to make use of the PHP exec() method to copy the webpage via the Linux tee command (piped off a Linux cat command) to achieve a similar effect as ob_get_contents() / file_put_contents()
Another issue that might be going through your mind about the PHP ob_ methods is whether they can be heirachical, and yes, they can, and would like to direct you to this useful link … thanks. Also, remember to read up on the callback (first parameter) possibilities with ob_start()
So hope this gets you thinking about PHP ob_ ideas, and will finish off reminding you of a .htaccess use of these PHP functions we talked about previously, below, when we presented Apache .htaccess Apache .htaccess Autoprepend Autoappend Primer Tutorial.
Previous relevant Apache .htaccess Autoprepend Autoappend Primer Tutorial is shown below.
Apache .htaccess Autoprepend Autoappend Primer Tutorial
Today’s tutorial continues the discussion regarding a big area (of knowledge) of Apache and PHP website usage and would like you to reread Linux diff Primer Tutorial, way below, to get the context (of what led to the first interest) that got developed in Apache .htaccess and mod_rewrite Primer Tutorial as shown below. Expertise in the use of .htaccess (or by changing the httpd.conf Apache webserver configuration file) can really help improve how much the search engines acknowledge your website (ie. SEO), particularly if you can arrange for “short URLs” in this way, or by some other approach.
So today we discuss a method of prepending and appending PHP code acting on the HTML webpage content.
If you examine the tutorial’s picture you’ll see the Coriolis tutorial on the local MAMP webserver before and after a change. You would first think that this is just a change to index.php (see yellow directory listing), but are you sure? The times on the Firefox browser for the Before scenario and index.php listing show the same minute of the day, so it is possible that we did the Before scenario at 4:09, raced over to the editor and made the file changes for the web modification within that same minute, then waited five minutes (presumably to allow the 4:12 from Paddington to pass) before firing up the Firefox browser for the After scenario at 4:14. What are the chances of this, up against the use of .htaccess/global_prepend.php/global_append.php to use Autoprepend/Autoappend Apache httpd methods to make the change? Well, I’d say negligible, especially as the title of this tutorial is “Apache .htaccess Autoprepend Autoappend Primer Tutorial”, but also because you’ll see from the yellow listing that the times of .htaccess and global_prepend.php and global_append.php all fall between the Firefox Before and After scenarios.
Have a look at the three files that achieved it:
Do you see what’s going on? Hope so, because the implications are pretty big, as long as your Apache/PHP website allow .htaccess usage (see the AllowOverride discussion in the tutorial below). One last thing to note happens down the bottom of the picture where (hope you can see) the URL HTTP://localhost:8888/yui_colourpicker.php shows a YUI Colour Picker. It’s a Colour Picker feeling lonely. So why is a lonely Colour Picker significant. Well, call me balmy, but am overjoyed it is alone, because HTTP://localhost:8888/yui_colourpicker.php is down (ie. closer to the root directory) the website directory tree from HTTP://localhost:8888/Coriolis/index.php and is not affected by the .htaccess in the Coriolis directory. The implication of this is huge for this being an aid to you using this method to control user behaviour on your website. You can have a directory (and all directories up from it on the website directory tree) where you disallow behaviours you do not want via the use of well designed .htaccess scenarios. Please bear in mind though, that there is a small performance lag caused by whatever “homemade” logic processing is involved. So this is definitely a subject you should pursue off the links of the tutorial below.
A great book to read regarding this subject, and others is Web Design for Developers by Brian P. Hogan (chapter 19 pp.273-275 talks about how you use this technique to help with mobile website design).
Previous Apache .htaccess and mod_rewrite Primer Tutorial is shown below.
Apache .htaccess and mod_rewrite Primer Tutorial
Today’s topic is a big area (of knowledge) of Apache and PHP website usage and would like you to (re?)read yesterday’s Linux diff Primer Tutorial, below, to get the context (of what led to the interest). Expertise in the use of .htaccess (or by changing the httpd.conf Apache webserver configuration file) can really help improve how much the search engines acknowledge your website (ie. SEO), particularly if you can arrange for “short URLs” in this way, or by some other approach. The optimal URL for search engines is one that:
- Has no ? nor & (very hard with dynamically generated scenarios … HTML form element method=’POST’ can help a bit)
- Has no file extension shown (ie. no .html nor .htm nor .php nor .aspx etcetera etcetera etcerera)
- Ends with /
- Contains meaningful and apt words in the URL
Think about it. If you were running a search engine with the rules above you could tell a lot about the webpage without parsing any of its contents, and not even having to do any intensive parsing of the URL.
So Apache configurations allow for the remapping of URLs without the end user having to be aware of it in any way. In this tutorial we illustrate how this works on our local Apache MAMP webserver here on this Mac.
Some good background reading here would be:
- mod_rewrite
- AllowOverride
- RewriteBase
- RewriteCond
- RewriteEngine
- RewriteRule
- URL Rewriting for Beginners Tutorial
- URL Rewriting Tutorial
Link to the MAMP scenario’s .htaccess configuration source code is downloadable here and you should rename to .htaccess (but not clobber any existing working configuration files on your system, pleeeeeeease).
Now, a bit more about the thinking. If you are a regular of this blog you will know that a lot of use is made of the file ending _GETME which is this blog’s way of providing you a download (of code like PHP, which is not accessible usually in this way). Occasionally, when trying to show you the progression of code this blog resorts to a -GETME file existing along with the older _GETME in the same place. The purpose of the .htaccess is to call diff.php when that -GETME type of file is used as a URL (will be a fairly rare occurrence) and diff.php will work out that there are both files existant, and will use the Linux diff command to show the two files, and a Linux (or unix) version of the file differences. With proper configuration all -GETME‘s could be treated this way … cute, huh?
Yesterday’s relevant Linux diff Primer Tutorial is shown below.
Linux diff Primer Tutorial
The Linux (or unix) command diff is a powerful command line tool that does file comparisons at the command line of a Linux (or unix) operating system command line. When you are coding this type of tool can be very important. You may not like to do such tasks in the command line, and have to say that a GUI (on Windows UltraEdit (text editor) is brilliant, on Mac think TextWrangler does a good job here) type of comparison works better for me, and Source Control techniques work well for many programmers, but GUI doesn’t always gel with integration, and want to show you today how the Linux diff can be incorporated into your PHP code. In saying this, am recommending extreme care with this, as its misuse can have bad implications for the whole website to be exposed to the outside world. Balancing this up against wanting to have a tool for users of this web blog to (have a more automated way to) be able to see the comparisons of files of changing code, as in yesterday’s tutorial, have decided to show the workings of this, in the rudimentary way it is used here. At the other end of diff, its output can be used by patch to make diff an even more powerful tool, and there are links about all this below.
Some good background reading here would be:
- diff (Linux or unix diff command)
- exec (as interface to use with PHP on the web)
- patch (as a way to use diff output as input to Linux or unix patch command)
So … why does the picture for this tutorial not show a Linux command line screen? Well, today we show you the power of the combination of Linux commands and the PHP way to access these commands (in our case with diff.php … the PHP exec() method). The follow up issue that tomorrow’s tutorial will address is the idea of an Apache web server configuration allowing a file “extension” to be mapped to a URL arrangement of your choosing … will save the idea here for that future tutorial, as this topic area is very big and needs the user to step back and think about, a lot, before considering.
Specifically, in diff.php (of the picture) it has a line of code …
exec(“diff ” . dirname(__FILE__) . “/one.one ” . dirname(__FILE__) . “/two.two > ” . dirname(__FILE__) . “/huh.huh”);
… to bring (Linux) diff results to the web for file comparison purposes … clicking on the picture of the tutorial shows a picture showing the link that got clicked to create the webpage of the front picture. By the way, am not showing all the code of diff.php today, and am sorry about that, but rest assured the line of code above is its crucial part.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
