Posts Tagged ‘coding’

Technical Difficulties

Saturday, 14 April 2018

Readers may have noticed some technical problems with this 'blog over the previous few days. I believe that the problems are resolved.

Recently, browsers have become concerned to warn users when they are dealing with sites that do not support encryption. Simply so as not to worry my visitors, I have tried to support the HTTPS protocol.

But I found that WordPress was still delivering some things with the less secure HTTP protocol, which in turn was provoking the Opera browser to issue warnings. At the WordPress site, I learned that I needed to modify two fields.

Unfortunately, changing these two fields broke my theme — my presentation software — so that fall-back text, rather than the title graphic, was sometimes displayed; but I didn't discover the breakage for a while, because the symptom wasn't always present. Ultimately, I realized that something were amiss. I tracked the problem to inconsistencies in how WordPress determines the protocol of the URI of the 'blog versus that of the directory holding the themes.

I recoded my theme to handle this inconsistency. (In the process of this recoding, my 'blog was made still more dysfunctional over several brief intervals.) My code is now sufficiently robust that it should not break if WordPress is made consistent in these determinations.

Not Following the Script

Monday, 13 April 2015

I frequently run across the problem of websites whose coders silently presume that all their visitors of interest have Javascript enabled on their browsers. Yester-day, I found this presumption affecting a page of someone whom I know (at least in passing), which prompts me to write this entry. (The person in question did not generate the code, but could suffer economic damage from its flaw.)

The reason that one should not presume that Javascript is enabled on the browsers of all visitors is that Javascript is itself a recurring source of security problems. Careful users therefore enable Javascript only for sites that they trust; very careful users enable Javascript only for sites that they trust and even then only on an as-needed basis; and paranoid users just won't enable Javascript ever. Now, in theory, the only visitors who might interest some site designers would be careless users, but we should look askance at those designers and at their sites.

(And trusting a site shouldn't be merely a matter of trusting the competence and good will of the owner of the domain. Unless that owner is also owner of the server that hosts the domain, one is also trusting the party from whom the site owner leases hosting. In the past, some of my sites have been cracked by way of vulnerabilities of my host.)

A designer cannot infer that, if-and-when his or her site doesn't work because Javascript is not enabled, the visitor will reälize that Javascript needs to be enabled; many problems can produce the same symptoms. Most of the time that sites don't work with Javascript disabled, they still don't work with it enabled. Further, the party disabling Javascript on a browser might be different from the present user; the present user might have only vague ideas about how web pages work. (An IT technician might disable Javascript for most browsers of users at some corporate site. Some of those users, perhaps very proficient in some areas but not with IT, may be tasked with finding products for the corporation.)

The working assumption should typically be that Javascript is not enabled, as this assumption will not be actively hurtful when Javascript is enabled, whereäs the opposite assumption will be actively hurtful when Javascript is not enabled.

The noscript element of HTML contains elements or content to be used exactly and only if scripting has been disabled. That makes it well suited to for announcements that a page will work better if Javascript is enabled

<noscript><p class="alert">This page will provide greater functionality if Javascript is enabled!</p></noscript>
or not at all if it is not enabled.
<noscript><p class="alert">This page requires Javascript!</p></noscript>
(It is possible to put the noscript element to other uses.) So a presumption that Javascript is enabled certainly need not be silent.

However, in many cases, the effect got with Javascript isn't worth badgering the visitor to enable Javascript, and the page could be coded (with or without use of the noscript element) so that it still worked well without Javascript. In other cases, the same effects or very nearly the same effects could be got without any use of Javascript; a great deal that is done with Javascript could instead be done with CSS.

A Useful Bit o' PHP Code, Set Right

Monday, 16 June 2008

I came upon someone's ancient 'blog entry in which he or she attempted to present what would be a useful PHP function. Unfortunately, the code has a few bugs.

A dynamic webpage may seek data from various sources, including data passed by GET and POST methods (which is how web forms normally), persistent data in cookies (stored on the client but provided to the server with each visit), and persistent data on the server.

Towards that end, PHP maintains five associative arrays: $_GET, $_POST, $_COOKIE, $_REQUEST, and $_SESSION. ($_REQUEST combines the contents of $_GET, $_POST, and $_COOKIE.) To access a variable named user sent by POST method, one would refer to $_POST["user"], and so forth.

The 'blog entry in question may have been written before $_REQUEST was introduced; in any event, the author had two good ideas:
  1. Avoid errors resulting from trying to access variables that don't actually exist. If no variable user was passed by POST, then $_POST["user"] throws an error. To avoid that sort of thing, the author checks for the presence of the variable before attempting to access it.
  2. Combine the variables in $_SESSION, as well as those in $_GET, $_POST, and $_COOKIE. Indeed, session data is more analogous to cookie data than is cookie data to data transmitted by $_GET or by $_POST.
The problems with the actual code are these:
  • If the server is not maintaining session data, then the attempt to use $_SESSION will itself cause an error.
  • There is an attempt to get cookie data from the array $_SESSION.
  • In the aforementioned attempt, the array is treated as a function.
Here's a version of the code that fixes those problems:
function getvar($var_name)
{
  if (array_key_exists($var_name, $_GET) == TRUE) $ret_value = $_GET[$var_name];
  else if (array_key_exists($var_name, $_POST) == TRUE) $ret_value = $_POST[$var_name];
  else if (session_id() != "")
  {
    if (array_key_exists($var_name, $_SESSION) == TRUE) $ret_value = $_SESSION[$var_name];
  }
  else if (array_key_exists($var_name, $_COOKIE) == TRUE) $ret_value = $_COOKIE[$var_name];
  else $ret_value = ""; 
  return $ret_value;
}
PHP also provides analogous associative arrays for other global variables, but what unites the variable types of the five here is that they are commonly used in session-tracking — keeping data associated with a specific visitor as she moves through one's site. Possibly, getvar would be better named something else, if not distinguished by being made a member of some class of objects.