I found myself needing to get the path to the current script and its directory in a local Node JS script recently. In Common JS scripts, that is available by __filename or __dirname globals, but it isn’t available by the same means in ES modules. Instead, there is import.meta.url, which can be used to get at the directory name if needed, like:
I’ve been playing with JS lately, including ES modules and building with Rollup, Babel, and Terser, along with other accessories. One thing I’m disappointed with of ES modules in the Nodejs ecosystem is dealing with third party imports. Using the “bare” specifiers that Node expects works fine in that environment and thus tools running in it (possibly needing helpers), but they don’t work at all directly in the browser. This is discussed in this post by Jake Archibold, for instance.
The xmlrpc.php file of my WordPress blog recently got hit by a single bot some 5000 times over a half hour period recently. I temporarily disabled all visitors and then limited it to just blocking the specific IP via Apache conf (htaccess).
I bought a short domain name in part so I could have a short email address that was easy to share. Unfortunately, I’m finding it to sometimes confuse people or require more effort than expected to spell out.
One of Cogneato’s clients noticed that Recaptcha wasn’t working on their site. The checkbox wouldn’t check at all. I noticed that there was an error like “Unexpected token in JSON at position 0” in the browser’s console log. Since this was one of our really old sites, I figured it might have some sort of inadequate polyfill for JSON.parse(). I saw that the site was using Prototype.js, so I looked through the script to see if it was overriding that method, but it wasn’t. That did put me on the right track, though, to find the Stackoverflow answer that solved it for me.
Prototype was overriding the now browser standard reduce() method of Array.prototype with its own, incompatible functionality. The solution was simply to remove that method from the “prototype.js” file. We weren’t using the special Prototype functionality anywhere, so this didn’t cause a problem. If we were, we’d probably have to duck punch the browser’s functionality to handle both method signatures.