One of the things which I have not done quite properly, would have been to put back-links to all the different pages that make up my site. Much of my Web-site has been written by me using a text editor, and I haven’t even committed each Web-page to being an HTML 4 or an HTML 5, either of which would require that I put a <DOCTYPE> tag.
And so still taking the lazy route, what I am going to do here is provide a table of contents. After all, the WordPress.org engine can also simplify my life when it comes to composing plain-old HTML:
This is a gallery of actual photos I shot:
This is a loose, original collection of pages, which have as a theme, Computer Generated Images (CGI) (:1) :
This is an SSL-Secured site, hosting ‘eGroupWare’. There is something to be understood about this though. In order for me to have obtained an SSL Certificate,
I needed to go through CACert, a Certificate Authority which most browsers don’t recognize. I have no idea why anybody would be interested, but I will list it here anyway (:2) :
The above site is secured via SSL, just so that I myself will be able to log in to it remotely, and not have my password compromised. By default,
a browser will complain that the site is not to be trusted, unless the user has gone to the following site first, and installed their CA certificate, which signed my certificate:
A curious user would go to their section indicated with “Root Keys”, and to follow the instructions there.
(Edit 01/14/2017 : Presently I am not using my CACert Certificates, instead using Lets Encrypt. And the main advantage, is that these more-recent certificates are recognized by most browsers out-of-the-box.)
And finally, a link back to this blog’s main page:
(Edit 01/14/2017 : This blog is generated by a collection of PHP server-scripts – aka CGI scripts – and uses HTML-5. This is a form of HTML which advises content-providers against using the old formatting tags for Italic, Underscore and Bold, instead suggesting Strong or Emphasized.
Because this blogging engine observes HTML-5 100%, the pieces of text which seem underlined, are generally URLs which the reader can click on.
When we use a Desktop or Laptop, our browser allows us to hover over these hyperlinks with our mouse, and displays a bubble which describes what sort of link it is.
But, when we use a tablet or a smart-phone to read a Web-page, there is no hover-support, because we usually do not use a Bluetooth Mouse. In such a case, some readers might have overlooked the fact, that each underlined segment of text is in fact a link, unless they were to tap on that link.
Generally, readers do not tap on random places within pages of text, unless they already know that the pages contain hyperlinks.)
1:) One fact which I am also trying to highlight is that while the domain-name ‘dirkmittler.homeip.net’ is of no intrinsic value to me, I do instead own the domain-names ‘www.dirkmittler.net’ and ‘www.dirkmittler.com’ . Both of these lead to a Web-forwarding service, but each works slightly differently. Anything which gets fetched via www.dirkmittler.net , simply sends the browser to dirkmittler.homeip.net , in a way that will be obvious in the URL bar. OTOH, www.dirkmittler.com will try to display the entire site located at dirkmittler.homeip.net , as a Frame within a dummy page, at …com .
This can affect whether your browser learns to associate my ‘favicon’ with my site in your Bookmarks. Web-sites are allowed to have favicons, which are icons that will be associated with them on the client-side PC. Not only that, but the favicon does not actually need to be named ‘favicon.ico’ , which is usually used. Mine is actually called faceicon.ico , and is indicated to be my favicon to your browser, with the appropriate <META> tag. It has happened that somebody made an attempt to fetch this icon explicitly from the root folder of my site, and could not retrieve it, because of my peculiar naming of it.
The container page at www.dirkmittler.com is so simple, that it fails to set even an appropriate Browser-Window-Title of my choosing, and also has no favicon set at all, which is where your browser would look for one. And, because www.dirkmittler.net is simply a redirect, it too might leave no favicon in your Bookmarks.
Too bad for favicons. I find that in many cases they just do not work, for various reasons…
Note: As of January 21, 2016, I have decided to create a copy of my file ‘faceicon.ico’, and to name that copy ‘favicon.ico’. One reason is the fact that when we install bundled HTML content, the only way to integrate the favicon can often be, just to leave the file by the standard name.
2:) If you ever tried to fetch an httpS:// version of one of the above links, aside from the eGroupWare one, and run into an error message, this was probably not your fault.
There was a time in the past, when I was experimenting with embedding my Web-site into my Facebook page, using an iFrame. If you do not know what exactly an iFrame is, this is not of much consequence. It is a way of making a Web-page on one server (in this case mine), appear as if embedded in the page on another server (in this case Facebook). And the technical fact is, that Facebook usually displays its pages with an SSL-secured, httpS:// link.
According to a rule in Web-design, if the page we are embedding an iFrame in to is already an httpS:// , then whatever page we are embedding must also be an httpS:// . This is only logical. There is no way to make the identity of the container page secure, if it contains non-secure iFrames. And to meet this goal, I once did try to make my entire site httpS:// .
But then because of certain problems with that experiment, I removed most of my SSL-secured content. What I may have easily forgotten to do however, was to remove any references to the old links on certain public sites. And that would probably have been the reason, fw some people tried in vain to call them up…
(Edit 01/14/2017 : As of lately, I am offering SSL-Secured access to my whole site, but the CGI-scripts that generate links have been instructed to generate http:// links, not httpS://, because the httpS:// links are not usually as useful. Therefore, even if the reader fetches the original URL as an httpS://, every link within the page displayed will default back to an http://. So the httpS:// version is really only meaningful on pages, that have been set up by me as such. And ‘eGroupWare’ is the only current example of that.)
I think that covers it.