javascript

For the past few years, my workflow for editing videos for my YouTube channel was the following:

1. Write and record narration / 'A-roll' using a teleprompter
2. Import recording into timeline, and chop out silent portions manually using the blade and/or range tools
3. Work on the rest of the edit (adding 'B-roll' and inserts).

Step 3 is where the vast majority of editing time is spent, especially when I need to add in charts, motion graphics, etc.

This is a quick blog post, mostly for my own reference.

I finally got sick of a certain government website thinking that preventing pasting passwords into certain forms was some sort of security feature, so I am documenting my workaround in Safari for stupid forms written by compliance-minded folks (the same who think that expiring passwords every 30 days leads to any kind of better security).

In Safari, select Develop > Show Javascript Console (or press ⌥⌘C, that's Option + Command + 'C')¹.

Paste the following into the console and press 'Enter':

var allowPaste = function(e){
  e.stopImmediatePropagation();
  return true;
};
document.addEventListener('paste', allowPaste, true);

Now you can paste to your heart's content.

¹ If you don’t see the Develop menu in the menu bar, choose Safari > Preferences, click Advanced, then select “Show Develop menu in menu bar.”

React seems to have taken the front-end development community by storm, and is extremely popular for web UIs.

It's development model is a breath of fresh air compared to many other tools: you just clone your app, and as long as you have Node.js installed in your environment, to start developing you run (either with npm or yarn or whatever today's most popular package manager is):

And then you have a local development server running your code, which updates in real time when you change code.

But when it comes time to deploy a real-world React app to non-local environments, things can get a little... weird.

For most modern projects I work on, there are usually multiple environments:

...aka, avoid the annoying Javascript error below:

Many themers working on Drupal 8 sites have Contextual menus and Quick Edit enabled (they're present in the Standard Drupal install profile, as well as popular profiles like Acquia's Lightning), and at some point during theme development, they notice that there are random and unhelpful fatal javascript errors—but they only appear for logged in administrators.

Eventually, they may realize that disabling the Contextual links module fixes the issue, so they do so and move along. Unfortunately, this means that content admins (who tend to love things like contextual links—at least when they work) and up not being able to hover over content to edit it.

There are two ways you can make things better without entirely disabling these handy modules:

File this under the "it's a very bad idea, but sometimes absolutely necessary" category: I was working on a site that wanted to use a particular font for headlines throughout the site, but the client detested one particular character (an ampersand), and requested any time that character were to occur in the page title, it would be swapped out for a different font.

If at all possible, you should avoid doing what I'm about to describe—but in the off chance you need to have an automated way to scan a string of text and change the font family for one particular character, this is what to do:

First, you need to create a special CSS class that you can apply to the individual character, so in your theme's CSS, add something like:

For a recent project, I needed to migrate anything inside <script> and <style> tags that were embedded with other content inside the body field of Drupal 6 nodes into separate Code per Node-provided fields for Javascript and CSS. (Code per Node is a handy module that lets content authors easily manage CSS/JS per node/block, and saves the styles and scripts to the filesystem for inclusion when the node is rendered—read more about CPN goodness here).

The key is to get all the styles and scripts into a string (separately), then pass that data into an array in the format:

For a complex Drupal node form I've been working on for flocknote, I have a relatively complicated image switching functionality that lets people change an imagefield on the node (either when creating a new one or editing an existing node), and once the imagefield is changed, some custom jQuery code will grab that image and display it in the form, for a very WYSWIYG-like experience (the node looks almost exactly the same when editing/adding as it does once the user saves the node).

One problem is that images can be arbitrarily high (though they're resized to 600px wide), and I can't easily get the height of the image through any traditional means. If I were grabbing an already-saved imagefield image, I could throw the image height into the JS settings for the page. However, getting a dynamically-added image's height/width values is surprisingly tricky using JavaScript, at least if you take a look around the web and try using many people's suggestions (which work great if the image was already loaded with the page's content, but not if the image is dynamically added, or if the image hasn't yet loaded on the page.

After staring at a todo in my inbox for a few weeks, I finally got around to doing it on the flight back from Boston yesterday. I simply wanted an easy, quick, at-a-glance way of telling what time it was in different timezones/cities around the US (and eventually around the world).

So, I created Alltheti.me:

(as displayed on the iPad)

I've been wanting something like this for quite some time, and I finally got a few hours to play around with dates and times in PHP and JavaScript. The times may not be quite right when viewed in certain timezones, so I'd appreciate if any friends from outside US Central time could tell me if their own times are correct.

On one Drupal site I'm developing, there is an 'embed code generator' in one of the site's forms. This embed code capability is similar to Twitter's embeddable timeline widget, in that a user can select some parameters (colors, mostly), then some code (usually an iframe with the contents provided by an external site) is printed in a textarea, which the user can select, and paste into his own site's HTML.

To help the user in the task of selecting the code, the entire contents of the textarea or textfield is highlighted when the user clicks any part, which ensures that the user will get every last bit of code without having to select and drag his mouse around the text box (sometimes I've seen people missing part of a tag, which makes the embed fail to load). That's what we want to do, inside our own Drupal form.

First, in the drupal form itself (or via an hook_form_alter()), we need to attach a javascript file in our custom module (in this example, I assume you have a module called custom.module, and a js file named 'custom.select-helper.js' in your custom module's directory, inside a 'js' folder):

For some time, I've been using the most hackish ways of including custom CSS and Javascript in my site via themes and custom modules. The problem has been (at least, in Drupal 6) that the hook_preprocess_page() function, inside which I'd really like to include my drupal_add_css() and drupal_add_js() functions, due to the fact that it's easy to see what page I'm on, or what kind of page I'm on, is not able to add CSS or JS to the page, due to the order in which the hooks are fired.

I've often just put my JS and CSS includes (via the drupal hooks) into the end of my custom module file, instead of inside a function at all.

However, a much cleaner way to include your CSS and JS is inside your own implementation of hook_init(). For example: