PHP

 PHP  is a programming language and web server runtime environment used for many IndieWeb projects.

Projects

 * Falcon - much of it is in CASSIS as well.
 * Known
 * p3k
 * stapibas
 * Taproot
 * WordPress
 * ProcessWire
 * Kirby

Libraries

 * php-mf2 - Microformats 2 parser
 * mention-client-php - Client library for sending webmention notifications
 * indieauth-client-php - Sample implementation and helper methods for an IndieAuth client.
 * php-comments - Helper for parsing and presenting comments from external sites
 * representative-h-card-php - Find the representative h-card for a given page
 * more libraries on the indieweb Github

Articles
Articles about the use of PHP, especially for software that you are expected to download and install on your own domain:
 * http://rachelandrew.co.uk/archives/2013/10/17/unfashionably-profitable/

Silos
Silos using PHP:


 * Facebook
 * Tumblr

UTF8
While there are a number of symptoms (weird looking characters, one character split into two), the problems with UTF8 handling in PHP happen for a handful of different reasons. Here are some suggested fixes for some cases.


 * check the HTTP header returned, it should have:"" if it does not then you may need a line like this in your PHP code before it outputs any HTML:
 * header('Content-type: text/html; charset=UTF-8');

session start failed
If you get an error like:  Warning: session_start [function.session-start]: open(/home/.../tmp/sess_..., O_RDWR) failed: No such file or directory
 * Look like the server can't write to /home/.../tmp/
 * so either it used to be able to, or it used to write to some other path
 * ssh in, and see what the permissions for /home/tantek/tmp
 * Or it's possible the session.save_path configuration changed. http://us2.php.net/manual/en/function.session-save-path.php

Possible resolutions:
 * If your webhosting is a shared server
 * start a ticket with your hosting provider, OR
 * add this code to your PHP application somewhere before session access: 
 * This code auto-creates the PHP session storage directory if it doesn't already exist (inspired by the  suggestion at, but tightened up with a conditional and tighter perms)
 * You may (should) consider providing additional error handling if the  fails, and at some point provide the user an error message describing the error in enough detail that they can either file a support ticket with their webhosting provider, or ask a specific question in an appropriate community.
 * 2014-08-07 undefined: These steps worked for me this past week using Falcon on shared webhosting. If Please only edit these instructions if you are documenting how you actually solved a problem firsthand, not how it might or should be possible.
 * OR write a completely different non-filesystem method of session handling.
 * See: http://websec.io/2012/08/24/Shared-Hosting-PHP-Session-Security.html for specific suggestions.
 * If this is on your local dev setup (e.g. yourdomain.dev on your laptop)
 * check your local dev php.ini to make sure it is setting session.save_path, if not fix it.
 * don't know where is your local dev php.ini?
 * create a file like phpinfo.php on your local dev setup with: ""
 * go access that phpinfo.php e.g. if you put it in a test directory: yourdomain.dev/test/phpinfo.php
 * look for "Loaded Configuration File:" and it will tell you where is your local dev php.ini,
 * don't have a local dev php.ini? if you see: "Loaded Configuration File: (none)" then you need to make one
 * look for "Configuration File (php.ini) path" in that same output from above.
 * go to that directory and look for a php.ini.default file
 * copy it to php.ini e.g. with "cp php.ini.default php.ini"
 * if you get an error like "cp: /etc/php.ini: Permission denied" then you need to use sudo : "sudo cp php.ini.default php.ini"
 * restart your local dev setup Apache, e.g. in a terminal window on your local dev machine: sudo apachectl -k graceful
 * if you see an error/warning like: "httpd: Could not reliably determine the server's fully qualified domain name" ignore it. Your local dev setup should work now.
 * if you instead (or also) saw an error like: "httpd not running, trying to start (13)Permission denied: make_sock: could not bind to address [::]:80 (13)Permission denied: make_sock: could not bind to address 0.0.0.0:80 no listening sockets available, shutting down Unable to open logs" then you forgot to use sudo . Try again with the exact sudo apachectl -k graceful command above.
 * 2014-08-07 undefined: These steps worked for me this past week using a Macbook Air running OSX 10.7 and default Apache/PHP. Please only edit these instructions if you are documenting how you actually solved a problem firsthand, not how it might or should be possible.
 * Hopefully that fixes the "Warning: session_start" error. If not, please ask in IRC and document further description/details below this item.

Fatal error memory exhausted
Can run out of memory on servers sometimes, and give a message like:


 * e.g. on http://yottabytes.info/?p=10497 (on 2014-06-08 15:28 EDT): "Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 32 bytes) in /home/johnkrol/public_html/wp-includes/post.php on line 1961"
 * Examples on: WordPress, Drupal , and Joomla

Recommendations
To fully avoid this problem one needs to figure out what the maximum amount of memory ones PHP process can need, check what amount of memory that is available on ones server, subtract any non-PHP processes from that amount of memory and then divide the remaining memory with the maximum amount of memory ones PHP process can need. The resulting number is the maximum amount of PHP processes one should run at once and ones server should be configured to never accept more than that or else be at the hands of the even worse fate than the mentioned white screen of death: The eternal doom of swapping that results when processes starts to use swap memory and processes therefore take much much longer to run and as a result more and more requests piles up so that the server sometimes can't recover itself at all but needs to be shut down.

Strict memory limits and limits on amount of parallel PHP processes are meant to avoid such swapping issues, but shared hosting often put very restrictive memory limits making it hard for larger and more demanding PHP applications like Drupal and WordPress to fit inside of that. The alternative is often to look at either managing a VPS oneself and configure that to fit ones application as just described or to get a managed offering from a hosting provider or a PaaS and ensure that it gets configured correctly.

An added complication when it comes to the LAMP stack is that sometimes the MySQL server is run on the same server as the PHP is and then compete for the same memory, which makes it even harder to figure out how much memory each process can be allowed to consume with the result of much stricter memory limits to be on the safe side.