Why is CiviCRM so ugly? Out of the box, a CiviCRM public contribution page is surprisingly ugly. Worse, if you ask your designer to make it look better, they are likely to take a long time, grumble loudly, and then maybe a year later it starts looking ugly again. It's a bit tragic that this is sometimes the first experience of people with CiviCRM, and since it's not likely to get fixed any time soon, here's a post explaining a bit of why, and how to remediate the issue. Why is CiviCRM so ugly? My first answer to this question is technical, but I'll try to make it accessible to the casual reader. A visitor's "objective" visual experience of a web page, is a product of: a. their device and browser (an iphone using safari, a desktop using chrome, a tablet using firefox, etc.) b. the html of the page c. the css (cascading stylesheets) d. the page's javascript When you're looking at a CiviCRM page, then you're looking at collection of html+css+js t
A couple of weeks ago, I decided to spend a few hours on a Friday afternoon improving my backup process for my Blackfly managed hosting service . Two weeks later, I've published my ongoing work as an update to my backup-rsync project and have decided to share it with you. You might think I'm trying to compete for "least click-bait like title ever", but I'm going to claim this topic and project might be of interest to anyone who likes to think about refactoring , or who is implementing backups for container-based hosting (like mine ). Definition "Backup" is one of those overloaded words in both vernacular and computer-specific use, so I want to start with definitions. Since "a backup" is amongst the least interesting objects (unless it contains what you absolutely need in that moment), I think it's more interesting and useful to define backups functionally, i.e. A "backup process" is a process that 1. provides a degree of insuranc