Password Protect Posts Created via Gravity Forms
A quick little plugin that sets the password for posts created via Gravity Forms. This came about as the result of a faculty request today. In this case it’ll grab the first form field and use that for the password. You could hardcode it into the plugin itself but I thought this gave a bit more flexibility. With this option you can make that field something that the user could set or you can make it hidden and set it consistently for all submissions.
Simple but maybe handy for someone else.
I want to be like Alan Levine someday but as I slowly progressively acquire the necessary coding skills I often make do with various kinds of semi-programistan hackery. Today was an example of that and so worth a bit of blogging. Jesse Goldstein, one of a cadre of most favored sociologists, sent me an email asking how hard it’d be to do a few things with his course site for Understanding Capitalism. He wanted the front page to have – three columns- each from a separate category a way to highlight items of import in the leftmost column a static chunk of text in the leftmost column There are lots of ways to do this. I’m actually confident I could write a child theme to do this . . . but it was fun to do it without that and to do it in about 30 minutes as we sat at the . The Theme Jesse course started out with the tried and true Twenty Fourteen theme. It’s a nice theme but not really the one I’d choose for something with three columns. I’ve really been enjoying Flat Bootstrap lately. It’s nice and clean both in the code and in the presentation and it’s, as the name implies, built on the Bootstrap framework which makes all sorts of neat tricks […]
In terms of basic accessibility guidelines each page should have only one H1 element. In WordPress that’s usually built into the template and is usually the title of the post or page. I was thinking about that last night and wondered if we should just remove it as an option from the TinyMCE editor in WordPress. Removing options goes against my typical stance but I couldn’t think of any scenarios that demanded an H1 element but plenty of scenarios where offering it seemed like it’d create confusion. A brief perusal of the WordPress Codex’s TinyMCE section led to the code above. I put it in our generic network-activated plugin for Rampages. Next steps could include integrating a filter in kses to remove/replace H1 elements with H2 elements but that’ll wait for now as it seems a chunk more aggressive.
This is why things are more difficult than they might be . . . a story of why I have no idea about anything or maybe it’s a parable of complexity and human frailty. In the beginning, we created a WordPress Multisite install and turned on BuddyPress. To make the groups works correctly we network activated bbPress. As a result, anyone logged into their accounts who visited any other rampages site became a Participant of that site (a bbPress user role that allows forum participation). People got very nervous about people being in their user roles. Other people became very unhappy their My Sites list had too many sites. I had to figure out two things as a result. First, I needed to stop auto-Participant association. I eventually found a way to do that but I still had to deal with the stuff that already happened. The right way to do it was to delete the users who were participants across the multisite. But . . . at that time we couldn’t access our database through anything but php myadmin and it wouldn’t run because the database was too big. So I had to treat the problem and strip the sites from the displayed list. Fast forward a year or so. At this point, we were able to turn off […]