web notes - a blog

I am using Smarty Templates extensively in a custom application. The application relies heavily on both PHP .ini and Smarty .conf files.

The .conf files had boolean settings, meaning values set to the literal strings of “true” and “false”, and when I read them in, with $smarty->config_load(’file.conf’);, my booleans were converted into either nothing (false) or 1 (true). I am using them as literals - so the conversion was not good.

I just started looking into changing my code to compensate, when I decided to review the Smarty documentation again. The booleanize setting allows you to disable the conversion from false to nothing and true to 1.

An enthusiastic thank you to the Smarty team!

:D

*** This post and link superseded by the ‘color map’ blog (see above) ***

The link provides a set of instructions and code which allow you to read the CSS files from a target application, then read CSS files from an existing site, and map the colors from the existing site into the target application, using sed.

This is brute force design, it would be very valuable for rapidly skinning an application to help a potential client visualize your application delivering their site.

The success of the approach is affected by the colors of both designs, this is a very simple method, the number of colors will impact how well they map.

The basic idea is to convert the colors from RGB into HSV, then reorder the HSV code into VSH - so the brightness takes precedence. In this case, it is assumed that the lightest colors will map to each other. Hue is virtually disregarded by its position.

The mechanics of the process are functioning as I wanted them to, although I haven’t tested it with live sites.

It also creates a shell script to generate image files of the colors, using ImageMagick, which is interesting but not actually used.

Requisite knowledge: Linux, PHP, bash, sed, regular expressions helpful.

I tried to put the text from the above link in the blog, but it didn’t work. Too many bizarre character strings.

One of the easiest ways to make a server or application more secure it to reduce the publicly accessible information.

The above link describes how the versions can be suppressed in the HTTP headers to make it more difficult for people to identify the version of server software you are running, and the version of PHP.

This same principle should be used with applications. Any tag in the HTML that exposes the version should be suppressed.

With sincere thanks to the associated URL, this is .htaccess code that can be used with b2evolution to deny access to requestors who include http: or ftp: on the query string. This is slightly different than the other post - it seems to be working. [L,F] didn’t work as I would have liked.

.htaccess

RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*=(ht|f)tp\://.*$ [NC]
RewriteRule ^.*$  403.php [L]


# CATCH EVERYTHING INTO B2EVO:
# The following will allow you to have URL right off the site root,
# using index.php as a stub but not showing it.
# This will add support for URLs like:  http://example.com/2006/08/29/post-title
# Redirect anything that's not an existing directory or file to index.php
#
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ index.php [L]

403.php

header('HTTP/1.1 403 Forbidden');

I hope this is helpful.

These are my rapid development strategies.

Front2Back

Works well for simple sites where the page layout is very important.

1. Build the HTML/CSS framework of the screen

2. Create navigation and page stubs

3. Set up help, about, terms/privacy stubs

4. Create a login screen (if necessary), that does nothing, and a logout. This helps to establish the logic flow.

5. Build a home page

6. Build pages out in a logical order (it will vary), again, front2back - start with the way it looks on the screen, then build the server side logic.

Back2Front

Works well when the complexity and risk are related to server-side logic and interfaces, or when there is a designer and developer on the project.

1. Get the documentation, find the resources for the difficult parts

2. Choose the simplest task, for example, submitting access credentials, and get it working.

3. Define an object-oriented architecture and one class to support the requirements.

4. Get the OO code interface working
5. Break the OO code into two layers (if necessary), one a general interface, the other specific to the class.
6. Clone the OO code for the remaining data types
7. Create the view for one class, then use the same approach as before to define the display architecture. Strive to use only very basic HTML, so the design can be managed efficiently with CSS.
8. Refine the interfaces to make integration easy.