Hide wordpress password protected pages

A lot of the time it is not desirable to have a password protected post show up on your WordPress home page or recent posts list however it is the default behaviour.

This code is almost straight out of the manual, however it may help someone looking for a complete example with the plugin header/comment that is required for the file to be recognised as a plugin by WordPress.

<?php
/**
 * @package hpp
 * @version 1.0
 */
/*
Plugin Name: HidePasswordProtected
Plugin URI: http://hotchipsnsource.com/
Description: As per name
Author: hot chips n source
Version: 1.6
Author URI: http://hotchipsnsource.com/
*/
// Filter to hide protected posts
function exclude_protected($where) {
	global $wpdb;
	return $where .= " AND {$wpdb->posts}.post_password = '' ";
}

// Decide where to display them
function exclude_protected_action($query) {
	if( !is_single() && !is_page() && !is_admin() ) {
		add_filter( 'posts_where', 'exclude_protected' );
	}
}

// Action to queue the filter at the right time
add_action('pre_get_posts', 'exclude_protected_action');

?>

Save the code in a file named HidePasswordProtected.php and save it to your wp-content/plugins directory. Then just activate it from within the WordPress Plugins administration page.

There is one flaw with this, while viewing a single post if the next or previous post made was a hidden post the next and previous buttons will expose a link to a hidden page. I have not had time to dig into this as yet and as the posts are not actually accessible it’s not presently a priority. If you know the solution please leave a comment below.

Alternatively there are plugins available on the WordPress Plugins Directory, the ones I tried also suffered from the next and previous issue.

Modular Building Designer / Estimator Tool

Here are a couple of modular building design / estimating program prototypes I came up with. There is a Web App & Windows Version, the premise was to design and prebuild house as modules from substructure through to roof and sell them through an app, construction would be just placing the modules onsite and bolting them together hopefully reducing construction time onsite to a few weeks.

boxbuilder
Windows Version

 

Luhn Formula, Mod 10, Modulus 10, Credit card & BPay Number Validation

Hans Peter Luhn the creator and original patent holder for the Modulus 10 Formula left us all a legacy. Just about every time you enter your credit card details online you will be subjected to the Luhn check. If you’re not, the website you are visiting is likely to be a little on the dodgy side.

Mod 10 as it’s commonly known is not the only check that a payment number goes through before validation of a payment occurs, it is only really usefull to check for typing errors and kids who think they might like to try random numbers. The real work of checking a payment number is going to be done by the bank or credit card gateway that is used by the merchant. When a check with mod 10 is done prior to sending a request to the final checker, it cuts down on millions of electronic requests to the many various payment providers and thus goes a long way to providing a smoother overall experience to users.

So now to the reason why I’m bothering to write about the Luhn Algorithm. The reason is not so much to do with the algorithm but with implimentation for bPay. bPay is a non-instant payment system popular in Australia where I live. With bPay you never have to give the store or service any payment details, they give you a unique payment number for either each user/account or for each unique transaction made for their business. A combination of both user and unique transaction is also possible. bPay numbers can become large due to the large amount of users who utilise the service and the amount of tracking the business decides to use. It’s common for CRN’s (Customer Reference Number) lengths of well over 20 digits. This is a rather large number and when considering doing calculations on it a few consideratons have to be made to ensure you get results. Your common off the shelf mod 10 program/script may not be able to cope with such large numbers due to the limitations of the data type programming language, or lack of forethough when it was written. So the reason as to why I have written this post is now ready to be revealed, I tried to use an off the shelf script in PHP for bPay validation and it failed…sometimes..

The script I initially utilised was written for credit card verification (16 digits in length), somewhat smaller than the 20+ digits I wanted to work with. After integrating the script and adding all the required functionality to the website shopping cart I was working on, everything seemed fine. CRN’s and check digits were getting produced during the checkout process and I was able to verify the CRN’s with some third party mod10 programs. It was only after producing the required 20 CRN’s during the bPay application process that any Issue was raised. The bank kindly sent an email in reply stating that some of the numbers didn’t check out. Admittidly it took a while to work out the issue, In my defence it was only every now and again the script would produce an incorrect check digit number. I rewrote the script a couple of times before it even occured to me to break the number up into chunks. Sure enough by processing the number in chunks it didn’t produce randomly incorrect numbers anymore. Further investigation showed that when dealing with larger numbers instead of producing an error message PHP would still provide an answer but the accuracy could be questionable. After a Google I found the PHP Integers page and the following

The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that’s 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18. PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5.

Two billion eh! that’s 2,000,000,000 in the short scale of things. At the command line on my test server

[brendon@hotchipsnsource]# php -r 'echo PHP_INT_MAX;'

produced exactly “2,147,483,647″.

That is not even enough to hold the 16 digit credit cards that the script was created for, so what is going on?

~to be continued.

Geospatial-Distance Calculators

When working on http://www.dssa.com.au!LINK BROKEN! I had to figure out how to find the nearest driving schools to the users location. To do this I needed to geocode their address (convert their address to Latitude and Longitude) and check it against my database of driving schools. My database contained the driving schools addresses already geocoded so it was then just a matter of comparing the two. I created a Geocodetestsuite that compares the performance of various ways I have used to calculate the distance.

NOTE 4.11.2016: previously the performance of option 3 took the longest however with the resurrection of my blog I see that the microtime for it is not comparable with option 1. I have not had the opportunity to review why this is.

 

Geospatial – Redfearn

Someone wanted a php or javascript version of the Redfearn Geospatial Formula, I was bored and wanted a chanllenge so I reverse-engineered an excel spreadsheet from Geoscience Australia to create a php version. You can find the source code and script example here http://www.hotchipsnsource.com/redfearn.php.

B¤BMєiStєr the whirlpool.net.au forum member who originally wanted the script updated my version and created the reverse conversion, you can find his site here http://nuffcumptin.com/projects/redfearn/redfearn.php.

Christmas Hampers System – A Joomla! Component

A while ago a client asked for a way to sell christmas hampers online and I was more then happy to accomodate the request.

I ended up creating a Christmas Hamper System for Joomla! that intergrates with Mastercard Internet Gateway System.

http://www.hotchipsnsource.com/joomla-hamper-system !no longer available!

Orders can be placed any time of year and repayments deducted automaticaly from clients accounts throughout the year until christmas day when they receive the goods. Repayments can be made weekly, fortnightly, monthly or a once off outright payment. The system divides the total value of the purchase by the amount of repayment periods that are left in the year and deducts the correct amounts from the clients accounts on those days. If a payment is not able to be made due to insufficient funds it is automaticaly retried each day until it succeeds or is manually processed.

The client online purchasing was a streamlined one way process to suit the business process that was outlined for the original project and manual ordering and modifications can be done by staff in the administration section.

What I found was the way you program for Joomla! is well structured, I liked how it was setup to create an installer for the system and how easy it is to apply my custom component to a clients existing installation. If you follow the design pattern they have setout and don’t try to hack in some existing piece of software but rather create something for Joomla! that does what you need, the result is good.

It was a project I really enjoyed and a great way to learn about Joomla!.