For a site I’m working on I wanted the environment variable APP_ENV set to “local” in development and set to “production” on the live site (each environment has it’s own .env file). My configuration keep on getting overridden somewhere and returning “dev”.
If you are running into this same issue a pretty easy fix. Unset the variable in you .htaccess file and then the correct value will load from your .env file. At the top of my .htaccess file in the public root I have this then:
# unset the APP_ENV variable since it might have been set in Apache's vhost file and needs to be used from .env
Well, tonight I kinda freaked out our 8 year old son Miles. We has just sat down for his ritual of one episode of The Big Bang Theory before bed. Katie was looking though news feeds and mentioned that Trump had taken the Florida primary and that Marco Rubio was likely to suspend his campaign (then he did shortly there after).
“Well, I guess we’re moving to Canada” I said. Miles turns around with tears in his eyes. “Are we really moving? I won’t get to see my best friend [omitted] anymore?!”.
After a little while he was calmed down and went back to watching Sheldon swimming in a ball pool with Leonard chasing him. Bazinga!
Bazinga. That’s all I can say about the current political theater. I don’t think we’re going to leave the country over it though.
I found out a cool usage for composer that I didn’t know about; use it for installing WordPress plugins. I use Phing to do all my deployments (slowly moving towards continuous integration with Jenkins). I wanted a way to get the plugin files and include them with my deployment automagicly. Composer can download and extracting the plugin archive file rather than using the gui in the wordpress admin. This task can be done when all your other required libraries are installed.
I wanted to install Contact Form 7. In order for this to work you need to download the plugin from a custom repository, so I setup my composer.json file something like this:
I set the name of the repo to the “takayukister/contact-form-7″ and then used that as it’s require name with the current version (right now 4.3.1). The paths in the “extra” section tell composer where to put the plugin once it’s installed.
In my Phing build.xml I could then run this before any packaging tasks:
This is the first in a series of “today I learned” posts. Today it’s all about the pseudo element ::before and ::after. This isn’t new news to most I’m sure, but I’ve just recently started using these and think they are pretty cool.
Say you are working on a site where you have access to the styles but not the DOM. You need to add an element to the page without actually adding any markup to a page. That’s where ::before and ::after come in. You can add either of these .element::before or .element::after to add extra element to the DOM this way.
I created an example (albeit kinda crude) to show how to use the elements. The snowman’s torso is a DOM element and the head and foot are added via .snowman::before and .snowman::after css elements. Same with the hands, there’s a empty .hand element on the page and the left and right hands are placed with .hands::before and .hands::after.
One caveat I’ve found is if you want the added ::before or ::after to behave like a block element you must add content: ""; to your css in order for the element to display, otherwise it has no height or width.
It’s been a long time since I’ve updated this site so I figured I’d start from scratch with WordPress. I haven’t done much in WordPress up till now but I have some customers who are requesting it at work, so I guess it’s time to take the plunge. I still have many sites that I maintain that use Textpattern for the backend but I think from here on out I’ll be working with WP.
I’ve also be slowly removing the “Withremote” moniker from my identity. I really don’t have much time to work on new items anymore. I’ll occasionally work on a new idea for a new print but I don’t have the setup I used to for screen printing anymore, that’s a big part of it.