CyberD.org
C:\ Home » Blog » Archive for "Code" (?)

A Little Random Title Script

I made a little random title script for the movie review pages with more than one review. A little impulsive thing... that took 40 minutes to figure out. Ugh. Here's how it turned out though, in two parts. It's in JS.

First there's the header, that either shows a random title from a specific list, or if the user has JS disabled, a standard one:

<h1><script src="/theme/js/more-reviews.js" type="text/javascript"></script><noscript>More Reviews!</noscript></h1>

Then there's the script with the aforementioned list, and code to cycle through the titles randomly, above refereed to as more-reviews.js:

var r_text = new Array ();
r_text[0] = "More Reviews!";
r_text[1] = "Added Addages!";
r_text[2] = "Ongoing Opinions!";
r_text[3] = "Latter Ramblings!";
r_text[4] = "Future Views!";
r_text[5] = "Later Watches!";

var i = Math.floor(7*Math.random());

if (navigator.appName == "Netscape")
   {
   document.write(r_text[i]);
   }
else
   {
   document.write(r_text[i]);
   }

That's it! Depending on your number of titles you might need to change the formula below the list too. I tried using a solution that didn't rely on numbers at all first, but just couldn't get it working, so this is it.

This is what it looks like in action (reload page to see more):

It's such a simple thing, but I dug through such a huge mess of other methods before finding one that for some reason actually worked, that I felt like I needed to post about it. It's not all that strange this one did, but it's strange the others didn't. I still have no idea why. Something with the way H1 tags work? Something about including a JS script in a header? If you have any knowledge about such limitations I'd be intrigued to hear.

So, stranger who stumbled upon this post, if you're wise then feel free to send me a message, and if you're in the same situation - searching for a solution to the same problem, hopefully this will find you faster than it found me! And hopefully it'll work for you, too. It's just a little random random title script, but it sure took a big effort to get right.

The Anatomy Of XLSX Files

I work with webshops, and as such I work with .XLSX files a lot, and convert these to .CSV prior to import/export. It's the OS-independent format. The big standard. Also: the much bigger file! A 821KB XLSX is 87MB large as a CSV!! Considering the difference - even though they supposedly contain the same data, I thought I'd dig into the file format a bit, using this particular file as my example, and see how it really works and what they really contain.

I used to think XLSX files used some smart algorithms or formulas to effectivise the way they store data, like finding similar instances and grouping them together as one entity, or skipping delimiter symbols altogether, and instead using spaces or line breaks (which I assume take less space), but as it turns out it's nothing like that. They just use heavy compression, and if you change the filename you can see exactly what they contain - which is not just the worksheet itself (apparently only 8MB big, though, in XML format), but a lot of other resources, and even the image file for the script icon! Some very unnecessary things, I feel, but the file size does decrease drastically with compression.

Looking at the files, the worksheet I'm currently working with (it's a workbook with only one worksheet) contains these:

Read on...

Customizing WordPress MediaElement.js Audio Shortcode

I just spent something like 4 hours changing the default...

Original

...to this...

New!

...using this base stylesheet (don't miss pull requests #1 and #2 if you do the same), fetching certain snippets of code (all those related to color/background) from this custom skin made before WP had native ME support, cutting out an alignment bug in the vertical volume slider thing by changing the top:-21 to top:-11 somewhere in the code (you'll figure it out), and a few site-suitable margin and alignment adjustments later... it's not looking all that bad!

The documentation for MediaElement.js in regards to WP seems to be pretty much non-existent, and it took me quite a bit of research to finally figure out how to even change the width on these new shortcodes - much less do anything wild like adding rounded borders and different colors. This mostly because all styles and scripts related to ME are hidden within wp-includes, there's no official documentation, and the original code (at least the stylesheet) isn't at all structured with modding in mind.

I found a few pages advertising workarounds such as very specific CSS rules or using !important to override certain rules, but the best option is clearly to first dequeue the 'official' core-included MediaElement stylesheet (via your theme's functions.php), copy this stylesheet to your theme folder where it can be modified, and then include this CSS again either via a link in functions.php, via @import, or directly into your main .css file. I'm assuming one of the latter two options would cut down on requests while loading site resources... personally I settled for @import. The only caveat with this technique is that any updates to the core file, you'll have to make manually.

How to dequeue the official stylesheet is mentioned in the Read Me! for that basic stylesheet, and you can use the same method for any other parts of the ME library, like the JS files. There's some useful info on such files here, along with info on custom event handlers, etc.

Also, if you want playlists with download links, see this. And if you want playlists in the first place, there's this plugin. Hopefully this post will serve as useful reference for others than myself! You can see a live version of the custom player here.

Narrow Columns & Wide Text

Do you write Eifel Tower with a lowercase or uppercase 'T' in 'Tower'? Apparently yes. Uppercase. That is how you write it. Meaning it must be the Eifel Tower and not the Eifel tower. Just something I've been wondering about...

Moving on: I just made some drastic changes in the site stylesheet! I read an inspiring article on the perfect paragraph while whimfully tweaking the layout today, and with some trial and error turned this previously very blocky and justified body of text into something hopefully much easier to read.

You may notice text sizes are suddenly incredulously large, paragraphs are stylistically narrow, previously regular-length paragraphs now look huge, and a bunch of layout elements are inadvertently messed up.

But it is easier to read... right? Not just because the text is bigger, but because there are fewer words in each line, because the lines are shorter not just in word length but in actual width - so you don't need to move your eyes so much from side to side to read, and because the spacing between words is even and the previously pro-longed white spaces don't become like 'boundless gaps' for certain autistic (I think it was?) individuals. There's no justification for justifying text!

And this is the optimal character amount per line, a balanced 50-70, even if it is mostly going towards and maybe over that high end 70. But it used to be 129. For newcomers, this is how it used to look:

The Old Style

I'm still not entirely sure this is the perfect format. I find myself suddenly writing shorter paragraphs to better suit the layout. Blank space fills up incredibly fast. I wonder if posts in the archives are still readable with this style, or if I'll have to revise them and shorten random segments of text so they don't take up an entire page. But then again, the practice of writing less is a good practice, and one it wouldn't hurt to start using!

What do you think? I think I'll leave it like this for a while. See if it sinks in. See if - once I've found and fixed all the odd quirks such layout changes inevitably cause - I do like this formatting better after all. After not daring to move higher than 13.4px in textual size over the span of the last decade, this is a sizable change.

Using Foreign Characters In Filenames

I thought I'd type up a post on what characters to and what characters not to use when it comes to naming files.

First off, the basics: don't use /\?{}#*&"':<> or |

These are all restricted system characters used for other purposes, and depending on what OS you use, it shouldn't even be possible to enter them while renaming a file. Though it feels like this goes without saying right now, it didn't always. I've learned this by trial and error over the years.

Also: never use spaces in file-names you choose to upload. It's good practice to replace those with a - or suitable supported symbol of choice. File-names with spaces do work with modern browsers, but that's thanks to the browsers recognizing this as a common mistake people make, and the file-names are actually renamed on the fly by either the browser or a server-side script for them to work each time they load. You've probably seen the occasional %20 in the address bar. That's a space.

The reason I'm posting this post however is not because of spaces, or any of the characters above, but because of å, ä and ö, the final three characters of the Swedish alphabet. Maybe this also goes without saying for some of you veterans, but I just recently discovered that these characters are also ones you should avoid.

I recently uploaded a bunch of images with Swedish names, and these letters all produced a replacement similar to the %20 for spaces, but rather than through the browser they were in the actual filenames themselves. Ä became Ä, lowercase ä became ÇÏ, ö became Çô, and I have no idea about the others. I haven't researched the matter, but obviously whatever variant of Unix is being used on my server (I don't know much about that... yet) doesn't support these characters, and I'm guessing no other foreign letters either.

Moral of the story: stick to the 25 validated, working characters of the English alphabet and common supported dividers such as dashes or regular brackets whilst naming files. It's not just good practice for online use, but for whenever you plan on moving to another platform, sending a friend a file, etcetc. And you never know when you will until you do!

In my case, I discovered this little error a year or two after uploading the images because a few images weren't being displayed correctly on an old draft I'd just decided to post (secondary moral of the story: don't wait so long!). I looked around for solutions, and found a plugin to easily rename these files in both database and directory to avoid any potential conflicts. Picture below.

Media Rename Screenshot

I did try other alternatives, but the above worked best for this specific purpose: renaming names and database entries individually, with a custom value.

Hope this might be useful knowledge for someone somewhere out there pondering characters! That's all.

My 'Custom Upload Dir' Story

Here's a little causerie in code about a little problem that's been hanging around in the back of my mind for a few years, that I finally did something about. If you're not working with or interested in WP, this might be a blog to skip reading. Short story, long blogpost, and it all starts...

A few years ago, I installed Custom Upload Dir. It's a one-of-a-kind plugin that lets you specify a custom upload folder within the base upload folder you've specified in WP, using a series of placeholders to modify directory structure based on things like file type, date, user, etc. I didn't need any of these extra modifiers, I just wanted to add an additional upload directory with a name of my choice for new files, but couldn't do this via WP since changing your upload directory directly by default changes the URL for all already uploaded images as well. So, I used this nifty plugin to start building a sequence of numerical sub-folders within the base directory that I'd switch between as they filled up over the years. On that note, it would be nice with a simpler plugin that automatically creates and shifts to a new directory when the current upload folder reaches a specified amount, creating this new directory based upon a naming pattern you specify. If any reader just so happens to catch onto the idea, let me know! I'd love to use it!

Anyway, I had previously used img/ as my base directory for all uploads, and was now planning to change this to work with the new directory pattern above. But since WP stores all meta-data links in relative form, I couldn't search and replace these links in my database with a new URL. There was just no URL to search for, and all images had unique filenames so there didn't seem to be a pattern I could use to search and find either. I thus changed my base directory to img/1/ and initiated my new practice of sub-folders within this sub-folder, leading to my images getting stored in img/1/, img/1/2/ and img/1/3/ and so on. I planned to change this later on, easily moving everything to the root folder, but I never figured out how.

Eventually, I changed the base directory back to img/, and moved all sub-folders into this directory, keeping the 1/ as just a sub-folder in the series. I searched and replaced all full URLs to these images in my post content, where the links were absolute, but couldn't do anything with them in post-meta, the table in which media library entries were stored. So since then they've worked in my posts, but not in the back-end where I browse these images.

A few days ago I decided on a whim to try this again. I opened up PhpMyAdmin not sure how I'd be able to accomplish this, but in exploring the database structure I quickly realized that all attachment images were stored in wp_attached_file entries within the wp_postmeta table. Wouldn't it be easy if I could just automatically search through the entries and add the folder number between table name and entry title? Aha. I exported wp_postmeta as an SQL file, opened it up in my favorite search and replace program (in this case TextRep 2.0, NoName Software), and searched for all wp_attached_file fields there were. I started the search and replace by searching for the first words in large series of images, like this:

wp_attached_file', 'One-Piece
wp_attached_file', '1/One-Piece

...but soon realized that using single letters would be much quicker! I searched by both upper and lowercase letters, like so:

wp_attached_file', 'O
wp_attached_file', '1/O
wp_attached_file', 'o
wp_attached_file', '1/o

...and 50 searches later, it was done!

You could probably do this via phpMyAdmin too, if you know how, but personally I found it much faster and easier to do it this way. Were my upload folder troubles entirely over? I looked through the postmeta file I'd downloaded and realized to my agonizing aggrevation that the thumbnail URLs remained unchanged. I had only changed the URLS to the images. Thumbs are stored in larger chunks of annoying text that look something like this:

a:6:{s:5:"width";s:3:"580";s:6:"height";s:3:"500";s:14:"hwstring_small";s:23:"height=''96'' width=''111''";s:4:"file";s:16:"One-Piece-40.jpg";s:5:"sizes";a:2:{s:9:"thumbnail";a:3:{s:4:"file";s:24:"One-Piece-40-200x200.jpg";s:5:"width";s:3:"200";s:6:"height";s:3:"200";}s:6:"medium";a:3:{s:4:"file";s:24:"One-Piece-40-280x241.jpg";s:5:"width";s:3:"280";s:6:"height";s:3:"241";}}s:10:"image_meta";a:10:{s:8:"aperture";s:1:"0";s:6:"credit";s:0:"";s:6:"camera";s:0:"";s:7:"caption";s:0:"";s:17:"created_timestamp";s:1:"0";s:9:"copyright";s:0:"";s:12:"focal_length";s:1:"0";s:3:"iso";s:1:"0";s:13:"shutter_speed";s:1:"0";s:5:"title";s:0:"";),

The really annoying thing with these chunks of text is that the numbers before the filenames for the thumbnails don't necessarily match. In one place it could be s:16, in another chunk s:18. It's a serialized array, where the numbers are apparently defined by the number of bits in each textual string. So, what did I do? What could I do? Nothing. I gave up. I changed the wp_attached_file URLs, but no wp_attachment_metadata data at all. I couldn't figure out how to do it, and neither could Google. I uploaded the postmeta SQL anyway to at least solve part of the issue aaand... it worked! The images worked. The thumbnails worked. Everything worked. As it turns out, I'd done all I needed to do!

To explain this totally unexpected surprise, I'm assuming either the wp_attached_file stores not only the filename (and relative URL if you are using a custom prefix as I am) but in fact the file info it's entirety, used as much for showing image info as for generating thumbnail info. That, or WP has changed how it handles this information and no longer generates thumbnail strings from uploaded images, relying on the image file to directly fetch such information when it's displayed. Of course I'm a total noob at this stuff and these are all very vague attempts at explaining this miracle. But the important thing is: that's all there is to it. :)

If I hadn't already started this blog ten years ago, I'd know till next time that how you structure the site from the ground-up is incredibly important. Choose a directory structure you like and stick to it, or make sure it's easy to change. Don't get lazy and stop naming, tagging and keeping track of files properly, and if you move the site: do an SQL export rather than a XML file export. Not that it's relevant to anything, but XML files don't store Media Library entries, so if you want to have a browsable gallery of all included images still available be weary of having them all wiped out! There are plugins for this, but none of them currently work with large directories and selections of files. But that's something for another post.

Read on...

Privacy   Copyright   Sitemap   Statistics   RSS Feed   Valid XHTML   Valid CSS   Standards

© CyberD.org 2017
Keeping the world since 2004.