A web-based tool for converting Audicity 1.3 and later labels to a CUE sheet.

A web-based tool for converting a CUE sheet to Audicity 1.3 labels.

Click on the View Site link for instructions.

A PHP script to perfom URL validation. It not only verifies the format of the URL is appropriate, but also uses DNS to determine that the host actually exists. If the host does not have a 'A' or 'CNAME' record, this function considers it not a valid URL.

As written, yes; however, it is a simple matter to modify the script to omit (comment out) the domain verification code.

No. Only ASCII URLs are supported. There are a number of approaches to handling international (unicode) characters in URLs listed in the PHP manual entries online. Please feel free to modify the code to support one or more of these approaches if you have such a need.

No. For that I recommend the excellent is_email PHP script by Dominic Sayers. I have used it often and find it does a superb job.

The only required file is is_url.php. Install it somewhere where your website will be able to find it. Including it in you PHP script with include() or require_once() and then call the is_url() function. See the is_url_test.php script for an example.

An Apache .htaccess file and PHP script combo to facilitate URL redirection of wildcard subdomains. This allows your DNS to be setup so *.domain.com points to the redurl script, which will then redirect the http/s request based on the actual subdomain.

The domain forwarding provided with most hosting packages has two distinct disadvantages.

First, you have to use their control panel to create forwards. That can be cumbersome and cannot be scripted and often does not take effect immediately. With redurl, you only need to edit the lookup table - a plain text file - and the effect is instantaneous.

Second, most forwarders created by the control panel method do not handle user-supplied URI and QUERY_STRING segments (ie, the path/file and variable parameters in a URL.) The redurl system deals with both.

The redurl script captures the REQUEST_URI and QUERY_STRING portions of the incoming URL and then appends them to the same components of the target URL.

For example, let's say you have a subdomain named test.domain.com that is setup to forward to the URL http://www.elsewhere.com/me?ln=en.

If all you do in a browser is go to http://test.domain.com, then you will be taken to the target URL exactly as it is setup.

But let's say you enter something like http://test.domain.com/search. Now, redurl will capture the incoming URI of "/search" and append it to the URI of the target URL, and you will go to http://www.elsewhere.com/me/search?ln=en.

Or, if you enter http://test.domain.com?pg=1, then redurl will capture the query string and append it to the target. You will be redirected to http://www.elsewhere.com/me?ln=en&pg=1.

And, of course, you could have both a URI and query in the incoming URL, so http://test.domain.com/search?pg=1 will take you to http://www.elsewhere.com/me/search?ln=en&pg=1.

A wildcard subdomain is similar to an email "catch-all" address. In email terms, the catch-all handles messages sent to any recipient not specifically defined. So if you have accounts for 'john' and 'sue' and an email for 'bill' arrives, it goes to the catch-all account.

In domain terms, the wildcard handles any subdomains that are not specifically defined. You might have domain.com, and www.domain.com and store.domain.com. If someone attempts to go to info.domain.com and wildcard domains are enabled, then rather than get a 404 page not found error, they are redirected to the handler for wildcards. This means any and all subdomains are "valid" and it is up to the wildcard handler to determine what to do with them.

redurl is such a handler.

The redurl script can only redirect http/s requests. This is because the redirection is handled at the HTTP request stage, not the DNS level.

Yes. You can setup domains -- such as *.domain1.com, *.domain2.com and so forth -- to all point to the same redurl installation. The script can deal with multiple domains. It can even support the use of wildcards in it's own configuration -- that is, if the subdomain 'test' is setup with a domain of '*', then 'test' for any known domain will be redirected to the same target.

The files in the download contain comments explaining how to install and configure. There is an assumption that you know how to install and edit a PHP file on your host, and also how to install and/or edit Apache .htaccess files.

A quick-and-simple database table browser. Includes a viewer and editor, as well as query/filter tools. PMB is built around the excellent phpMyEdit, which you will also need to download from their website. If you're familiar with installing LAMP apps, PMB+PME should take only a few minutes to get installed and running.

• Alternate site

PMB is built around the excellent (and free) tool phpMyEdit. If you cannot download the most recent version from their site, then you can download the version used to develop PMB using the links below.

• phpMyEdit 5.7.1
• phpMyEdit Docs

Installation instructions for phpMyBrowser are contained in the distribution package. The phpMyEdit instructions are in it's package.

phpMyBrowser's table browser is implemented using the phpMyEdit system. Please refer to their website for documentation on using the browser (ie, sorting, setting filters, queries, etc.)

FaqList is a PHP script to read a plain text file of FAQ topics and questions, and then create HTML output that uses <div> tags and javascript to show/hide the answers.

Frequently Asked Questions

Extract the contents of the faqlist archive into a directory. As deliverd the PHP script expects the faqlist.txt file (or whatever file name you choose) and the divtog.js file, to be in the same directory with the file that calls FaqList.

Use the LNE %$!function!$% facility. For example, you can place the following in the page content:

%$!include faqlist.php !$%
%$!funtion FaqList faqs.txt - FALSE !$%

Note the use of '-' to tell FaqList to use the default 'main' topic.

To output the entire faq file, with the main topic selected:

<?php echo FaqList('faqlist.txt', '', FALSE); ?>

To output the entire faq file, with a specific topic selected:

<?php echo FaqList('faqlist.txt', 'topicname', FALSE); ?>

To output only a specific topic from the faq file:

<?php echo FaqList('faqlist.txt', 'topicname', TRUE); ?>

All of the HTML elements have a class attribute. You can affect the appearance of the faq output by setting these classes:

• <ul class="faqlist">
  Define: ul.faqlist {}
  This list is used to list the faq topics.
   
• <li class="faqlist">
  Define: li.faqlist {}
  These are the individual topic bullets.
   
• <a class="faqlistt">
  Define: a.faqlistt {}
  Note the extra 't' at the end. These links are used for the individual topics.
   
• <p class="faqlist">
  Define: p.faqlist {}
  This is used to show the questions in a topic.
   
• <div class="faqlist">
  Define: div.faqlist {}
  This is used to enclose the answer to a question. The answers in the faq file are inserted into this div tag.
   
• <a class="faqlistq">
  Define: a.faqlistq {}
  Note the extra 'q' at the end. These links are used for the individual questions.

HitTrack is a LightNEasy 3.1 plugin that implements a hit counter (very similar to HitThingy) from within either the template or the page content.

HitTrack installs according to the LightNEasy plugin architecture. See the LNE manual for details. Installation instructions are also contained in the README.txt file included in the package.

The tracking mechanism itself is identical to HitThingy. Consult the HitThingy faqs for details. The big difference with HitTrack is that it knows how to automatically separate hits by page, and how to separate normal hits from admin-mode hits.

Because HitTrack is plugin for LNE, you kind of need LNE running to provide a demo. Functionally, the tracking method and the output are similar to HitThingy, so that demo (such as it is) shows the tracking at work.

HitThingy is simpler in many ways; however, it requires you to create a data file for each page, and to manually insert the LNE tags to call it. HitTrack does this automatically, and this alone is enough to make it the better choice.

HitTrack also allows you to modify your counter output format from the setup console, without having to modify the php source. You can use html to format your counter or you can have simple text. The counter output can be suppressed (via the setup console) so your hits are counted but not displayed. What good is that, you ask?

HitTrack provides a nice, simple screen for viewing your hits for your entire site. Even if you've turned off counter output, you can still use the setup console to track hits. This is the 'killer feature' that makes HitTrack a far better solution for LNE than HitThingy.

This is a v4 version of v5's complement to file_get_contents().

Put the fileput.php file into a directory where it can be accessed by your web site's PHP scripts.

In your code, you simply include() or require_once() the fileput.php file. Then, in your script, you can call the function to write to a file.

Not really, except perhaps as an example of how to backload v5 functionality into v4.

This is a simple, standardized way to read the contents of a directory.

Put the filelist.php file into a directory where it can be accessed by your web site's PHP scripts.

In your code, you simply include() or require_once() the filelist.php file. Then, in your script, you can call the function to read a directory.

Not really. It's rather simple.

A simple PHP hit counter (used on this site) to track the number of times a page is generated. It maintains a counter in a text file, and when called increments that counter and returns the new value.

Put the hitthingy.php file into a directory where it can be accessed by your web site's PHP scripts.

In your code, you simply tell HitThingy() where the text file to be used to store the count is located. Note that the file does not have to exist. If it's not there, HitThingy() will create it.

<?php echo "Page Hits: ".HitThingy('hits.txt'); ?>

Yes. To track multiple pages simply call HitThingy with a file name unique to the page. For example, if you track the current page in a variable named $PAGE, then HitThingy("$PAGE.txt") will create a counter file for each page.

You can also track hits for other elements. For example, if you need a count of total hits, then in addition to the above you would also put something like HitThingy('site.txt').

Not exactly. The HitThingyParse() function will read all the hit files in a directory and return an array with the filename and count. This can be used to very simply create a report.

Note that using this function will require you to also have the file_list() function, which is available from this site.

<?php
 
// load file_list() function for reading directories
 
require_once($SCRIPT_DIR.'filelist.php');
 
// call HitThingyParse to gather hits into an array
// and then display with foreach (simple, but shows
// the basics of how to get the job done)
 
$hits = HitThingyParse($myHitDir);
 
foreach ($hits as $file=>$count) {
  echo "$file - $count\n";
}
 
?>

HitThingy illustrates how to do simple text file reads and writes, which may be of interest to newbie PHP coders.

It also shows how to mimic the PHP5+ file_put_contents() function in PHP4, which might be of use to some folks. (See also the fileput script located elsewhere on this site.)

The demo link jumps you to the bottom of the page, where the counter is displayed. If you like to see numbers increment, then refresh the page once you get there.

• A separate hit file is required to store the counter for every page.
• The counters are incremented EVERY time a page is generated. No effort is made to filter "non-events", such as page reloads or multiple accesses from the same remote address. "Robot" hits, such as Googlebot and Baiduspider, are also not filtered out. (For somewhat more sophisticated tracking, have a look at the TrackThingy script located elsewhere on this site.
• There is no admin interface, and no statistics are generated other than the array returned from HitTrackParse().

A simple PHP hit counter to track the number of times a page is generated. It maintains a log in a text file, and when called the particulars for the page are saved. TrackThingyParse() can be used to read this file and return an array with hit counts (using a variety of grouping criteria.

Put the trackthingy.php file into a directory where it can be accessed by your web site's PHP scripts.

In your code, you simply tell TrackThingy() where the text file to be used to store the count is located. Note that the file does not have to exist. If it's not there, TrackThingy() will create it.

<?php TrackThingy('tracker.log'); ?>

Yes. Unlike HitThingy, which tracks individual pages in separate files, TrackThingy is designed to track all hits in single file. The REQUEST field can then be used to subdivide hits by page (or other criteria.)

Yes. A number of files (tt*.php) are profided. These are a report generation system for TrackThingy. The tt.php file is simply an example of how to use the module on your page.

The report module intentionally avoids the use of styles and other formatting, which allows you to more easily wedge the module into your layout. I suggest wrapping the module in a <div> with an ID, and then use CSS to style the elements in the form.

TrackThingy illustrates how to do simple text file reads and writes, which may be of interest to newbie PHP coders.

It also shows how to mimic the PHP5+ file_put_contents() function in PHP4, which might be of use to some folks. (See also the fileput script located elsewhere on this site.)

• A single file is required to track page hits. This could lead to some performance issues on a very busy site.
• Page hits are tracked EVERY time a page is loaded. No effort is made to filter "non-events", such as page reloads or multiple accesses from the same remote address. "Robot" hits, such as Googlebot and Baiduspider, are also not filtered out. However, unwanted hits are easily filtered from any output results as the client info is captured.
• There is no admin interface.

A system for implementing custom http error handling. This makes it easy for your site to provide it's own version of 404, 500 and other errors. It includes the code that must be copied into .htaccess as well as a script for translating cryptic error numbers into titles and descriptions. It is also able to email the site administrator when a new error occurs, and to prevent repetitive emails from users who obstinately bang on a site when they receive an error.

Consult the README file, as well as the notes in the script and .htaccess files.

Installing it activates the code. You need only to setup the options in the PHP script.

The error output page itself is generated using normal HTML/PHP, so you can custimize that page if you so desire.

No, errors are not tracked separately. You'll have to check you http server logs for that. (Although, adding tracking wouldn't be difficult.)

There's a pretty good example of how to work with cookies, including using serialize/unserialize to store arrays in cookies (without all the confusion of the in-built way.)

Easy. Try going to http://grimblefritz.com/blah. You should get a simple 404 error page. Along with the error description, you should also see a message saying "The site administrator has been notified of this error."

Next, refresh (reload) the page. You should get the same page, but with a different message: "This error has already been reported." You will have to wait for 24 hours for the "reported" status to clear. That is time since the last attempt, by the way, not the first one.

If you want to see it again, just use another URI - /blah1, /yada, /skip, /fred... whatever.

• The typical install implements the handler for the entire domain. If this is a problem, you'll have to code your way out of it.