web notes - a blog

DataTables is AWESOME. I use it for list-based selection, table-based editing, data display and filtering and anything else I can think of because it is so robust that virtually anything is possible. Really.

If the dataset being used is fairly small (you may interpret small any way you like), DataTables client-side processing is amazing. It sorts and filters, updates all the navigation, lets you adjust the number of records displayed - as well as many more optional features - with very little effort.

Client-side processing - where filtering, paging and sorting calculations are all performed in the web-browser.

Ref: https://datatables.net/manual/data/#Client-side-processing

but

For client-side processing no additional data is submitted to the server

Ref: https://datatables.net/reference/option/ajax.data

The goal was to have a single client-side datatable which would display different content based on the user's actions. For example, 'list all the items with a status of "new" and a (time) segment of 1'.

HTML for the DataTable

<table id="datatable" class="display" cellspacing="0" width="100%">
  <thead>
    <tr>
      <th>Id</th>
      <th>Vendor</th>
      <th>Item</th>
      <th>Date</th>
    </tr>
  </thead>
</table>

JavaScript

var datatable;
$(function($){
    datatable = $('#datatable').DataTable(
         {
           "ajax": {
                        "url":  "data-10-1.php"
           },
           "columns":
           [
               {"data": "link"},
               {"data": "vendor"},
               {"data": "item"},
               {"data": "date"}
          ]
  });
  // Handle the click events
  $(".summary").on("click", function(evt){
        var target = evt.target, status, segment;
        if (target.hasAttribute("data-status")) {
            status=$(target).attr("data-status");
            segment=$(target).attr("data-segment");
            datatable.ajax.url("data-"+status+"-"+segment+".php");
            datatable.ajax.reload();
            datatable.draw('full-reset');
        }
    });
});

Notice that the URLs are variable. The status and segment values are passed in the URL itself, there is no POST or GET data.

Sample HTML which invokes the event handler. This HTML is inside the div with class="summary".

 <span class="details" data-status="10" data-segment="4" data-status-text="new">84</span>

In order to extract the status and segment out of the URL, you can use Apache RewriteRules, like so:

<directory /var/www/html>
    RewriteEngine On
    RewriteRule  ^(data)-(\d+)-(\d+)(\.php)$ $1$4?status=$2&segment=$3 [L]
</directory>

status and segment can then be accessed as $_GET variables. Be sure to validate them.

How does it work? As the user clicks on the spans, the event handler reads the data attributes and constructs a URL that is sent to the server. When Apache receives the request, it rewrites it to deliver the data embedded in the URL as GET parameters.

This post courtesy of Game Creek Video

If you want to test a script that will run as a cron job, or you would like to run a command line script repeatedly to test it, watch is a great tool.

watch -n [number of seconds between runs] [command to execute]

For example:

watch -n 60 php super-script.php

This is a very simple script to create users and set them up in a userdir enabled Apache environ.

#!/bin/bash
if [ "$#" -ne 1 ]; then
	echo "Usage: ./mkacct.sh <username>"
	exit;
else
	sudo useradd -m -s '/bin/bash' $1
	sudo chmod 711 "/home/$1"
	sudo mkdir "/home/$1/public_html"
	sudo chmod 755 "/home/$1/public_html"
	sudo chown "$1.$1" /home/$1/public_html
	sudo passwd $1
fi;

In some cases, environment variables are used to store configuration information. If the values are referenced from different sources, such as through a web server and on the command line, it is a good idea to define them in a single place and gracefully make them available.

This is one way to set the environment variables in one place, then source them into accounts for use (CentOS 6.4):

1. Create /opt/webapp/etc/appconfig/common and put the environment variables in it

export TEST_ENV_VAR="Test Environment Variable"

2. Add these two lines to /opt/webapp/etc/sysconfig/httpd

if [ -f /opt/webapp/etc/appconfig/common ]; then
. /opt/webapp/etc/appconfig/common
fi

3. Add these two lines to /etc/sysconfig/httpd

if [ -f /opt/webapp/etc/sysconfig/httpd ]; then
. /opt/webapp/etc/sysconfig/httpd
fi

4. Add this line to /etc/httpd/conf.d/webapp.conf (webapp Apache conf file)

PassEnv TEST_ENV_VAR

4. Restart Apache with service httpd restart

5. Test with http://webapp/phpinfo.php (<?php phpinfo(); ?>

6. Add these two lines to /home/admin/.bashrc - or whatever the account is that will use the variables.

if [ -f /opt/webapp/etc/appconfig/common ]; then
. /opt/webapp/etc/appconfig/common
fi

7. Test with echo $TEST_ENV_VAR

What this does is creates a common place to store the environment variables and makes them accessible to both Apache and the shell of admin (and any other account that includes them). That way, when a script is run as a cron job or on the command line, it has the environment variables all set. If new environment variables are needed, or if they change, the common file is updated as well as any others that reference the new variables. Then you restart Apache.

Many times when you are working with a web application on shared hosting, the server will create files. Depending on the server configuration, it is possible those files will be created by a user other than the account holder. If you are using shared hosting, and the server is running as 'nobody', 'apache' or 'www-root' you may not be able to delete the files.

This script determines the web server user with the whoami command, then finds and deletes any files it owns. Bear in mind it will delete them from the current directory down, so files higher up in the directory tree will not be removed.

<?php
$whoami = `whoami`;
echo $whoami;
$find = 'find -delete -user '.$whoami;
`$find`;

Be careful with this script, it may delete files you wanted to keep.

A good practice is to use the whoami display to see which user the server is running as, then use find -user server to find the files that were created. Once you've checked it, you can allow the script to run. Remember to run the script through the browser or using wget.