Programming

PHP: Converting titles to permalinks

0
2 years ago
by Nick in

Having the item title in the URL is a good way to improve SEO for your website. For example, /shop/adobe_photoshop_cs5/ is much more meaningful to users and search engines than /shop.php?i=83s9f8haj8dj. Unfortunately, not all characters are valid in URLs, which is where a permalink function comes handy to convert titles into a nice URL format. Permalinks usually remove all non-alphanumerical characters and replace spaces with underscores. “Adobe Photoshop CS5” is then converted to “adobe_photoshop_cs5”.

function permalize($input) {
	return str_replace(' ','_',strtolower(trim(preg_replace("/[^a-zA-Z0-9 ]/", '', $input))));
}

Note that you can use some special characters in URLs (like + and -), I usually like to remove them completely, but it is totally fine to leave them should you choose to.

If you don’t want to rely on a permalink to retrieve database data about your item, you can still insert the ID in the URL (e.g. /shop/34655/adobe_photoshop_cs5/ ). The permalink could then be discarded in the code while still providing better readability and SEO.

WordPress and Password-Protected Directories

0
2 years ago
by Nick in

WordPress adds a little code to your root .htaccess in order to catch all URLs on your website and process them. It works fine if you only have WordPress on your websites and normal files/folders. But should you have a password-protected directory, WordPress might catch the 401 page as well which results in never showing the login authentication box at all.

I tried to add additional RewriteCond and RewriteRule to catch the password-protected directories before WordPress does but without success. The trick is in fact much more simple than that. You simply need to tell Apache to go to a custom 401 page of your choice (it can be blank or the default page, doesn’t matter). You will then be prompted with a login box and let you proceed to the password-protected directory. Should the login be wrong, the custom page will be displayed. No more annoying WordPress url rewriting!

Here’s the code: (notice the usual WordPress code, you simply need to add the ErrorDocument line above it)

ErrorDocument 401 default

# BEGIN WordPress
<ifmodule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</ifmodule>
# END WordPress

The best way to write PHP code

4
2 years ago
by Nick in

PHP is quite flexible in the way you write code. You can write same code in about 10 different styles and it’s still going to work. The problem is when you try to read and understand someone else script. It’s either well documented or completely unreadable.

In my opinion, writing large blocks of documentation is, most of the time, useless and time consuming. It is possible write code in a way that it can be read by anyone with very short amount of documentation. It all starts with naming your functions correctly, dividing long blocks of code in short functions that are self-explained.

So I decided to share some best practices I’ve read or learned over time. Many of these tips are taken from CodeIgniter Style Guide.

Naming

// INCORRECT
function Getlastmessages()
function GetLastMessages()
function getLastMessages()

// CORRECT
function get_last_messages()

Sure the CamelCase version isn’t bad, but the best way to name methods is by separating words with an underscore.

You should name your classes the same way but by using an uppercase letter as the first letter. (ex: Get_last_message)

Constants also follow the same rule but all letters are in uppercase (ex: GET_LAST_MESSAGE)

HTML Output

Unless the HTML to output is relatively short, you should always close PHP, write your HTML and then open PHP back.

Use the short <?= tag (if enabled on your server) to open PHP to output a variable.

TRUE, FALSE and NULL

// INCORRECT
$var = true;
$var = True;
if($var == null) {}

// CORRECT
$var = TRUE;
$var = FALSE;
if($var == NULL) {}

Always write conditional values in uppercase.

PHP Files ending

As strange as it sounds, you shouldn’t close PHP at the end of PHP file. You should instead include a standard comment at the end and that’s it.

<?php
// PHP CODE HERE

/* End of file index.php
/* Location: ./application/index.php */

Why? Because PHP will close automatically as it reaches the end of the file but more importantly, it will prevent any whitespace or line breaks issues at the end of the file.

UTF-8 File Encoding and Unix line-breaks

Your code editor should always be configured to use UTF-8 encoding and Unix style line breaks. This will ensure compatibility with most languages and servers configuration.

(Adobe Air) Bring a window to front by clicking the systemTrayIcon

4
2 years ago
by Nick in

While developing an AIR application, I had an issue with bringing the application to front (above all other windows) when clicking the systemTrayIcon.

Usually, you would use the method:

systemTrayIcon.addEventListener("click", function() {
window.nativeWindow.orderToFront();
});

But doing so will result in… actually nothing at all. The window doesn’t move.
Using the same code on a menu item of the SystemTrayIcon will work, but not on the click action of the Icon itself.

Workaround:

Set the window property alwaysInFront to true and then to false:

systemTrayIcon.addEventListener("click", function() {
 window.nativeWindow.alwaysInFront = true;
 window.nativeWindow.alwaysInFront = false;
 });

Not the way it should be, but it works…

Go to Top