Recent blog posts
In yesterday's post, I talked about fixing up old PHP code to be safer.
There's another anti-pattern common in old PHP code, and that's mixing the display logic with the output logic. While some of this is inevitable, nowadays, the rule is to use a templating system like Twig to separate out even small bits of HTML code from the logic.
WordPress does this on the front end via Underscore templates, but configured to use Handlebars-like syntax.
This is a PHP class that does the same thing with PHP.
There are a lot of demos and tutorials about incorporating the wp.media image uploader and selector, but not much about the other parts of the library.
wp.media.views.Modal is a blank modal view, which the media modal uses as its default container.
This view is demo'd in the Media Guide, but it's not really discussed elsewhere.
Modal displays the large white box that contains the media manager. Within wp.media, it's used only two times.
I'm studying the wp.media library, and Backbone.js. I never really did anything with except toy programs with Backbone - and I didn't really grok it, so now I can learn it... post Angular and post-React. It's going backwards in time, but, still instructive because the Backbone.js idioms are different from the easier-to-use frameworks.
A lot of other books out there don't discuss selector specificity and the Cascade in enough detail. They don't talk about ways to organize your code, either. When you read this ebook, it'll make sense.
Originally from: 2007-09-26 15:17:44 -0700
This is a bit of code to add a floating box to your page that will let you switch stylesheets and fonts. I wrote it specifically to start trying out different "themes" and fonts, not to allow the end user to do these things. But the client will be using it to preview.
It's not fully parameterized, nor does it generate the HTML for the selects, so you'll need to hack the code.
I'm kind of bummed out. GoDaddy's free web page builder, InstantPage, isn't being given out with the domain anymore. I thought it was going to kill the website building business (meaning something I do for money) but the prospect of a nice page done in an hour or less, hosted for free, was just too awesome.
Maybe the free product was cannibalizing sales of their other products.
I've been writing HTML forever, but really never looked at the new HTML5 tags. For the most part, I'd devolved into using DIV and SPAN and FORM and a few other tags to code up webpages. That's OK for writing software, but it was getting pretty stupid when I was putting in code like DIV CLASS="address". A quick trip through the HTML5 tags revealed a cornucopia of tags relevant to writing academic papers and computer programming tutorials.
We all take it for granted that most sites will have a user registration system, and way to log in. We're used to it, and most people are unaware of how complex it is.
So, how complex is it?
It's around 15 different steps or screens.
I've done it a dozen times, and I think that's about right.
It's not hard, but there are a lot of little details to make it look reasonable and not completely goofy. I think it moves a little weird - and it should respond to both x and y axes, but doesn't.
This is a somewhat elaborate example of how to use conditional CSS and transitions to create a fluid, responsive stack of rectangles that are polite enough to stack up when the screen is narrow. The idea is I'm working on is to have a menuing system that stacks when the screen shrinks.
I don't know anything about CSS Transitions, so I made this little demo to try it out. It's ultra-simple, and I normally wouldn't post this kind of thing, but the examples I saw were a lot snazzier, so it was harder to read the code. (To this end, this is probably too fancy.)
Python and Django like snake_case.
AngularJS feels like Java, and likes camelCase.
HTML likes dashed-words.
MySQL docs like snake_case, but I see more PascalCase used in databases. It's case-sensitive, too.
Parse.com uses PascalCase for tables/classes, and camelCase for columns/properties/fields. That's like Java OOP.
Django likes to append _id to your primary keys.
So... the problems start to happen when one piece of named data is passed from one layer of the system to another. It's just a good policy to use the same names at all layers, if possible.