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.
web posts
Ansible, Vagrant, and Symfony `var` permissions
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.
Vagrant network IP change
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 192.68.56.0/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.
Ideas: Cascading Behavior Sheets, a declarative alternative to JS
I have had the idea for some time that the web ought to have a declarative format to define behavior on elements like it does for styles (CSS). It would be an alternative to JavaScript (JS) that would be as robust as CSS, simplifying adding and defining common behaviors. There are a lot of things sites do frequently that can take a fair amount of work for a new person to implement, as well as require a payload sent over the wire. For people who don’t need complications beyond standard, this could be provided by the browser with some configuration in a simple sheet. I think there should be a Cascading Behavior Sheet (CBS) standard for the web.
Potential advantages:
- 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
- declarative
- 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 has moved to Cloudflare for providing their DNS service. That is fine with me after they had an outage earlier in the year: Cloudflare DNS is pretty reliable.
Continue reading post "#3891"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.
jQuery AJAX and multipart form handling
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.
JS: ES Modules and Node bare specifiers via response rewrite
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.
Import maps are one solution in the works, but that requires explicitly mapping every dependency, which could get complicated fast when dependencies have dependencies. It also is only in draft stage and only works in Blink based browsers currently.
I eventually gave in to the idea of having server code rewrite the paths in the js file responses to point to a symlinked node_modules folder, similar to what is mentioned in this post by the Polymer project. I created a PHP test server for one of my projects that does this.
Fallback webfont and emoji
in
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.
Continue reading post "Fallback webfont and emoji"Fighting form spam
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.
Continue reading post "Fighting form spam"