<?xml version="1.0"?>

<!-- File name: index.xml (root)
BSD 3-Clause License

Copyright (c) 2021, 2024, 5 Mode
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its
   contributors may be used to endorse or promote products derived from
   this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-->

<?xml-stylesheet type="text/xsl" href="index.xsl"?>

<CONTENT>
	<ITEM>
    <ID>1</ID>
    <DATE>Thu October 14th 2021</DATE>
    <TITLE>Private dir, less voyeurs</TITLE>
    <BODY><![CDATA[
It is a good practice to separate the resources managed by the web server from all the other scripts, .inc or whatever can remain private to the application. Basically, you can quitely set a Public dir with your php router (usually the index.php file) and the static content of your web app; while in the Private dir you are going to set all the rest of your web app (that you will go to include through the router or other mechanism).
]]></BODY>
    <SEE/>  
		<SEE-URL/>  
		<TYPE>tip</TYPE>
    <CAT>security</CAT>
		<INDEX>1</INDEX>
	</ITEM>
	<ITEM>
    <ID>2</ID>
    <DATE>Thu October 14th 2021</DATE>
    <TITLE>Initialization: one file, easy life</TITLE>
    <BODY><![CDATA[
Having wrote just a small router with the classic *Hello World*, *Back to Life*, *Iron Clothes* actions.. you remain to decide where to initialize your new web application. There is no better way than including an ad-hoc init.inc file where to set all the needed resources, autoloader, session, cache, error handling, etc.
]]></BODY>    
    <SEE/>  
		<SEE-URL/>
		<TYPE>tip</TYPE>
    <CAT>deployment</CAT>
		<INDEX>2</INDEX>
	</ITEM>
	<ITEM>
    <ID>3</ID>
    <DATE>Fri October 15th 2021</DATE>
    <TITLE>Beautiful php, secrets included</TITLE>
    <BODY><![CDATA[
When you are going to write some code that needs to be *recognized* and *served* by the web server you can write it in a *beautiful* .php extension. When, instead, you are going to write some classes or some reusable code that just needs to be *included* and *not served* to the user it is the time to write a *secret* .inc file. The point is exactly that your frontend web server is most probably not configured to serve the .inc files. Remember that this choice is safe only when it is adopted in conjunction with a directory separation approach.
]]></BODY>  
    <SEE>Private dir, less voyeurs</SEE>  
		<SEEURL>#1</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>security</CAT>
		<INDEX>3</INDEX>
	</ITEM>
	<ITEM>
    <ID>4</ID>
    <DATE>Sat October 16th 2021</DATE>
    <TITLE>The oracle to my code secrets</TITLE>
    <BODY><![CDATA[
PHP language is continuosly evolving and assimilating new functionalities becoming more fast too. Beside this it is nice to have good coding practices and profiling tools to tune your own PHP code: Webgrind is surely the tool that needs to be in your coding bag. It is a web app, written in PHP, easy to deploy and easy to understand (that is never too bad); it makes use of Xdebug under the cover.  
]]></BODY>  
    <SEE>Webgrind</SEE>  
		<SEEURL>http://github.com/jokkedk/webgrind</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>tuning</CAT>
		<INDEX>4</INDEX>
	</ITEM>  
	<ITEM>
    <ID>5</ID>
    <DATE>Sat October 16th 2021</DATE>
    <TITLE>As simple as SimpleXML</TITLE>
    <BODY><![CDATA[
XML is the optimal approach to small quantity of data and nowadays manipulable in many ways, in PHP too. You can read an XML with file() and parse it by your own logic, with the mere help of reg expressions and string functions, uh? You can read an XML file and parsing it by events, uh? Finally, SimpleXML comes in handy letting us access an XML in object and properties fashion like in this way:

echo $content->tip[0]->body;  
]]></BODY>  
    <SEE>Basic SimpleXML usage</SEE>  
		<SEEURL>http://php.net/manual/en/simplexml.examples-basic.php</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>data</CAT>
		<INDEX>5</INDEX>
	</ITEM>
  <ITEM>
    <ID>6</ID>
    <DATE>Sat October 16th 2021</DATE>
    <TITLE>Performance at first glance</TITLE>
    <BODY><![CDATA[
Do not hurry John Doe, it is not arrived the time to scale yet.. However, there are some tuning practices we can always use with ease: 
- Take advantage of type hints since PHP ver 7.
- Set variable types with settype.
- Pass and "consume" arrays by reference.
- Use constants.
- Prefer explicit to implicit type conversions.  
]]></BODY>  
    <SEE/>  
		<SEEURL/>
		<TYPE>tip</TYPE>
    <CAT>tuning</CAT>
		<INDEX>6</INDEX>
	</ITEM>
  <ITEM>
    <ID>7</ID>
    <DATE>Sat October 16th 2021</DATE>
    <TITLE>Simplicity makes the trick</TITLE>
    <BODY><![CDATA[      
All of us feel fantastic making great programming. But for one reason or the others, who admitted finally along their careers that *doing it simple* is important was always right: it let us have managiable and reusable code with a strong cut on documentation and commenting. Do it simple for who? Clearly for ourself but mainly for all the other people who work with us and *consume* PHP.   
]]></BODY>  
    <SEE/>  
		<SEEURL/>
		<TYPE>tip</TYPE>
    <CAT>syntax</CAT>
		<INDEX>7</INDEX>
	</ITEM>
  <ITEM>
    <ID>8</ID>
    <DATE>Sat October 16th 2021</DATE>
    <TITLE>Null coalescing is yet your friend</TITLE>
    <BODY><![CDATA[      
Undubtly PHP function isset() miss a default value when all of us are searching to add it to its implementation.. Indeed it is quite *simple* to write our own *simple* custom function but let's do it more *simple*, the mysterious null coaleshing operator comes really in handy for our purpose:

echo $var1 ?? $var2;    
]]></BODY>  
    <SEE>Null Coalescing Operator</SEE>  
		<SEEURL>http://php.net/manual/en/language.operators.comparison.php</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>syntax</CAT>
		<INDEX>8</INDEX>
	</ITEM>
  <ITEM>
    <ID>9</ID>
    <DATE>Sun October 17th 2021</DATE>
    <TITLE>Polyfills from Classic ASP</TITLE>
    <BODY><![CDATA[      
Switching to PHP development it could be easy to find yourself sometimes breaking into obstruct syntax and not so simple-as-on-the-go instructions. On the obstruct syntax, you can fix your coding erasing the more naif or depracated or unsafe code (pay attention: it exists!). On the simplicity, you can find yourself within the need to replicate some simpler instuctions or ideas from other *worlds*. 

These are some string and date/time polyfills created behind Classic ASP:
]]></BODY>  
    <SEE>Classic ASP polyfills</SEE>  
		<SEEURL>https://github.com/par7133/phptips.net/tree/main/downloads</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>polyfills</CAT>
		<INDEX>9</INDEX>
	</ITEM>
  <ITEM>
    <ID>10</ID>
    <DATE>Sun October 17th 2021</DATE>
    <TITLE>Used to latest PHP modernity</TITLE>
    <BODY><![CDATA[      
Since PHP 5.6 lot of time has gone and lucky it is so: many years of support and bug fixing has been going on under development since there. Less fashinating is the fact that we need to keep our servers updated to the last version of PHP, and expecially thinking to your production server is not so *healthy*. Two news come useful for these cases. First, PHP latest versions have a good back compatibility with their ancestors. Second, devops software like Docker comes in handy to solve *little* deployment prbs. Anyway your *devview* should point to this doc: 
]]></BODY>  
    <SEE>Supported versions</SEE>  
		<SEEURL>https://php.net/supported-versions</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>deployment</CAT>
		<INDEX>10</INDEX>
	</ITEM>
  <ITEM>
    <ID>11</ID>
    <DATE>Mon October 18th 2021</DATE>
    <TITLE>Final gel to a brilliant skull</TITLE>
    <BODY><![CDATA[      
There are classes and classes. When we are going to write some *perfect* code following best practices and standards then the final keyword is certainly something we should take in careful consideration both on security and on efficiency side of our coding. When we are working on big project, strong versioning and many clients.. well, the full inheritance flexibility is certainly something desirable. 

Despite everything the Final keyword is definitely something you should check out: 
]]></BODY>  
    <SEE>Final Keyword</SEE>  
		<SEEURL>https://www.php.net/manual/en/language.oop5.final.php</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>oop</CAT>
		<INDEX>11</INDEX>
	</ITEM>
  <ITEM>
    <ID>12</ID>
    <DATE>Tue October 19th 2021</DATE>
    <TITLE>'Frictionless coding' mantra</TITLE>
    <BODY><![CDATA[      
Having a rich programming language at our disposal and freedom to invent and coding by our own genius and pragmatism.. let’s say that sometimes could be deleterious. Especially when we are building software with others, in a company, on Github, the rigor of some coding standards is something necessary to facilitate the shared work. About PHP, a cross-committee of the developer community time-to-time updates a set of coding standard recommendations named PSR. Relying on PSR coding standards, especially the more generic PSR-1 and PSR-2 ones, is something as *normal* as.. IDEs like NetBeans have software facilities enforcing their usage. 

Definitely have a look to the PSR coding recommendations: 
]]></BODY>  
    <SEE>PSR-2: Coding Style Guide</SEE>  
		<SEEURL>https://www.php-fig.org/psr/psr-2/</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>syntax</CAT>
		<INDEX>12</INDEX>
	</ITEM>
  <ITEM>
    <ID>13</ID>
    <DATE>Tue October 19th 2021</DATE>
    <TITLE>Records of network casualties</TITLE>
    <BODY><![CDATA[      
A certain number of advanced PHP network instructions exist almost in an uncovered fashion: as it is not good to advertise them, as it is not common to find ourself in the need of them. However, when things get hard to test and find out it could happen that working with dns records takes in less variables - ie. you are dealing with an host under load balancing or sites available in different geographical regions). In this cases checkdnsrr() or dns_get_record(), with different php support and implementation, come in handy:

$host = “phptips.net”;
print_r(dns_get_record($host, DNS_A));
]]></BODY>  
    <SEE/>  
		<SEEURL/>
		<TYPE>tip</TYPE>
    <CAT>net</CAT>
		<INDEX>13</INDEX>
	</ITEM>
  <ITEM>
    <ID>14</ID>
    <DATE>Tue October 19th 2021</DATE>
    <TITLE>Clients like cookies</TITLE>
    <BODY><![CDATA[      
Must be that session cookies are too sweet, this explains why Javascript persists to like them a lot.. PHP has a number of php.ini settings to protect sessions and among these session.use_strict_mode and session.cookie_httponly are some of the more important ones. *Strict mode* forces the session module to check for session IDs initialized by the module itself and not user generated. *Http only* forbids the cookies access by Javascript to the compatible browsers.
]]></BODY>  
    <SEE>Securing Session INI Settings</SEE>  
		<SEEURL>https://www.php.net/manual/en/session.security.ini.php</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>security</CAT>
		<INDEX>14</INDEX>
	</ITEM>
  <ITEM>
    <ID>15</ID>
    <DATE>Tue October 19th 2021</DATE>
    <TITLE>All paths take to Rome</TITLE>
    <BODY><![CDATA[      
Honestly one thing is to be anxious for best practices and one thing is to not care at all. Probably the right approach resides still in the middle. Other considerations come under the voice "PHP bugs and hacking", but this is out of the scope of this *tip*. However, if you want to close all in a *safe*, PHP supplies you with the php.ini open_basedir directive. Setting *open_basedir* with the root path of your web app you are going to force eg. PHP includes or fopen() calls to handle only scripts contained in that path.
]]></BODY>  
    <SEE/>
		<SEEURL/>
		<TYPE>tip</TYPE>
    <CAT>security</CAT>
		<INDEX>15</INDEX>
	</ITEM>
  <ITEM>
    <ID>16</ID>
    <DATE>Wed October 20th 2021</DATE>
    <TITLE>Unicode call to Multibyte</TITLE>
    <BODY><![CDATA[      
When we are going to develop a web application tailored for a broad audience, using Unicode, we should not forget about PHP itself. Indeed, PHP through the optional mbstring module gives at our disposal a set of functions named *multibyte string functions* that allow us to deal with unicode string with ease. And what does it mean to us choosing a multibyte string function like mb_stripos() instead of the *standard* stripos()? It means exactly looking at stripos() failing on unicode strings.
]]></BODY>  
    <SEE>PHP: Introduction to Multibyte strings</SEE>  
		<SEEURL>https://www.php.net/manual/en/intro.mbstring.php</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>int</CAT>
		<INDEX>16</INDEX>
	</ITEM>
  <ITEM>
    <ID>17</ID>
    <DATE>Wed October 20th 2021</DATE>
    <TITLE>Strict better than wrong</TITLE>
    <BODY><![CDATA[      
Playing around your code with strings (mainly if you are using them as a shortcut for arrays in your configuration file..) you can break into a little semantical problem of functions like stripos(): a 0 position of the needle in the hashtag could be evaluated as a false result. The fix using the strict comparison operator comes really in handy:

$bestSites = “PHPTips.net|..|”;

// This is NOT correct..
if (stripos($bestSites, “PHPTips.net”)) { 

// This IS correct!
if (stripos($bestSites, “PHPTips.net”) !== false) {
]]></BODY>  
    <SEE/>  
		<SEEURL/>
		<TYPE>tip</TYPE>
    <CAT>syntax</CAT>
		<INDEX>17</INDEX>
	</ITEM>
  <ITEM>
    <ID>18</ID>
    <DATE>Fri October 22th 2021</DATE>
    <TITLE>PHP with a performant FPM</TITLE>
    <BODY><![CDATA[      
The old but safest solution to run PHP by the Apache SAPI mod_php module seems to have been abandoned by the most. In fact, PHP now comes supplied in its package (on installations with —enable-fpm) with PHP-FPM, an high configurable and high performant FastCGI Process Manager. PHP-FPM has different settings but mainly can be configured to run in static (fastest response, but resources consuming), dynamic (fast response, process friendly) or on demand mode (slower response, resource friendly). Have a look to the following link for all tunable settings: 
]]></BODY>  
    <SEE>An Introduction to PHP-FPM Tuning</SEE>  
		<SEEURL>https://tideways.com/profiler/blog/an-introduction-to-php-fpm-tuning</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>tuning</CAT>
		<INDEX>18</INDEX>
	</ITEM>
  <ITEM>
    <ID>19</ID>
    <DATE>Fri October 22th 2021</DATE>
    <TITLE>PHP with a performant Apache</TITLE>
    <BODY><![CDATA[      
The Event Multi-Processing Module (MPM) of Apache allows us to tune the behavior of httpd responding simultaneously to more requests by the listeners threads, and set how to free up threads to serve new requests. Please note that in the recent Apache installations the tuned “mpm_event_module” doesn’t figure as a physical file but as a *static* module. Have a look to the following link for all possible settings:
]]></BODY>  
    <SEE>Apache2 and php fpm performance optimization</SEE>  
		<SEEURL>https://medium.com/@sbuckpesch/apache2-and-php-fpm-performance-optimization-step-by-step-guide-1bfecf161534</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>tuning</CAT>
		<INDEX>19</INDEX>
	</ITEM>  
  <ITEM>
    <ID>20</ID>
    <DATE>Fri October 22th 2021</DATE>
    <TITLE>PHP with a performant Nginx</TITLE>
    <BODY><![CDATA[      
Nginx is a light and high performant web server that can be used as reversed proxy (as frontend server to serve static content only) and is usually coupled with PHP-FPM. There is a lot of good documentation around how to tune performance of Nginx. However here're two directives to cut on server response time almost instantaniously:

# Use Thread Pools (http scope)
aio threads;

# Reuseport Socket Option (server scope)
listen 80 reuseport;
]]></BODY>  
    <SEE>Nginx Performance Tuning – Tips and Tricks</SEE>  
		<SEEURL>https://www.nginx.com/blog/performance-tuning-tips-tricks/</SEEURL>
		<TYPE>tip</TYPE>
    <CAT>tuning</CAT>
		<INDEX>20</INDEX>
	</ITEM>  
</CONTENT>
