I’ve upgraded my website to Symfony 5.4 from 4.4. I’ve continued on without Symfony Flex, as I had when updating from 3.4 to 4.4. The procedure was fairly similar to that, fixing any Symfony 4 deprecations and then updating the composer version constraints, fixing anything broken after that. I also switched from requiring the symfony/symfony repo to requiring individual components. It went fairly smoothly, aside from needing to fix a few things after the composer update.
I have moved to using VirtualBox VM’s for my local web development. I use Vagrant and Ansible to set them up. For my site, I use synced folders to share the site files from the local machine to the dev VM. This limits what permissions can be set on the files though, and doesn’t work well for Symfony’s var folder stuff, eg cache and logs. The normal Symfony permissions for those folders use ACL’s, but those cannot be set on Vagrant synced files. My solution was to create a /var/www/var folder to store such folders for any sites on the VM, and symlink them into place in the shared folder location. I did this with Ansible so that it would be reproducible. Since I ran into some issues getting it working, I thought I’d blog about it.
Apparently, an update to VirtualBox after version 6.1.26 limited the IP’s usable for network adapters on Mac / Linux hosts. They must now be in the 18.104.22.168/21 range, which is pretty limited and much less easy to remember or type than the 10.*.*.* that I had been using. I had to change my projects to all be in this range and spread out the IPs to avoid collisions between the various projects when I updated VirtualBox a while back.
robust forward and backward compatibility like CSS
simpler, easier to learn format than JS
little to write or think about for common functionality
little to send over wire for common functionality
more performant native implementation possible
familiar syntax to CSS devs
simple to connect behavior broadly to chosen selectors
cascade, @media, @support, etc to limit which and when behaviors apply
automatic handling of attaching and removing behaviors when they apply / don’t, including new DOM elements
maintain separation of concerns that keeping JS and CSS separate provides
Porkbun DNS seems to be down and has been so for the last several hours at least. I have added Fastmail nameservers to my NS list so that things work for the moment, since I get that as part of my account there. Can’t for my client though, who I had recommended Porkbun to.
I recently had need to submit a web form with file fields via AJAX. The application uses jQuery and was already submitting forms just fine without file fields using the .serialize() method to pass data to a jQuery.ajax() call. That didn’t seem to handle the file fields, though. Searching the internet, I found a solution using the browser built in FormData object.
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.
Recently I found that browsers will download a fallback webfont (@font-face) to try to find an emoji or other missing character. I was looking at the perf characteristics of my site when I noticed that the browser was downloading a webfont that wasn’t being used at all. After some digging, I found that the browser was going down through the full font stack to try to find an emoji I had added to that page, downloading the webfont on the way.
This is probably not a common setup, but I have a webfont in my font stack down stack from some similar common system fonts, as a fallback just in case. It uses a nice system font unless it can’t find it, in which case it uses the webfont, unless it can’t use that, in which case it uses a less desirable system font or the generic font class.
Cogneato has dozens of sites with openly submittable forms on them, and they have no doubt all had some level of problems with spam submissions. Bots, and perhaps people, like to share their links or services, try to hack sites, or whatever other nefarious or annoying purposes they may have through forms, which require some sort of server side processing, and will possibly result in human processing as well, such as with sent emails, database data, or comments on a website.
Spammers have gotten more sophisticated over time, and over the last year or two, have really started to hit Cogneato’s sites hard and get past the protections we had in place. We’ve had to add protections on forms that didn’t have them before, and use more techniques to attempt to detect spam. We’ve recently added a set of checks of the submitted form data and the submitter IP address that produces a score of “spaminess” that we can then use to block the submission if the score is above a threshold. That score script is the primary purpose of this post, but I will cover the other techniques we use as well.