I thought it might help somebody the way I’m currently managing my WordPress theme. First of all, I have to say it would be better to have an actual WordPress installation in my localhost, so it would be easier trying out changes (on themes and plugins) before committing them. I’m just too lazy for that, so I’d rather have only one running installation of WordPress on my server and a moving git repository for the theme alone. So this is how I do:
1. I have a Github public repository to share my theme (not like anyone is interested anyway)
2. I have another private repository in my server to store all the changes of the theme and actually update it.
3. I have a local repository in my computer for the theme.
4. The theme is actually stored at my_server_root/my_wordpress_path/wp-content/themes/bernatfarrero/
Let’s start out creating the local repository in your local computer:
mkdir bftheme && cd bftheme
scp -r my_server_root/my_wordpress_path/wp-content/themes/bftheme .
git init #We initialize the local repository
git commit -a -m "Initial commit" # And we make the first commit
We’ve just made a local copy of our theme and we’ve set up a local Git repository. Now let’s synchronize it with our server’s repository. In my server I have a special directory for all my repositories called repo. So, now I have to login via ssh to my server and do the following:
cd my_server_root/repo #this is were I store my repositories
mkdir bftheme.git && cd bftheme.git
git init --bare
git config core.worktree my_server_root/my_wordpress_path/wp-content/themes/bftheme
git config core.bare false
git config receive.denycurrentbranch ignore
vim hooks/post-receive #Open this file with your favorite editor and write inside it:
#!/bin/sh
git checkout -f
#Save it and close it
chmod +x hooks/post-receive #Give it running permissions
The denycurrentbranch set to ignore (or warn) basically makes the server not complain for having uncommitted changes on the remote repository. Even so, as we only want it to mirror our local changes, we don’t care. We’ve set the post-receive hook so it resets our repository to the latest changes received by our last push. Now in our local computer, we have to tell our repository who will be the remote:
git remote add origin username@host.com:repo/bftheme.git
git push origin master
And that’s it. We’ve established the connection between our local repository and the actual changes made public in our blog. In order to deploy your changes just do:
git push
And you should see them right away. If you do not, there will be some problem with the paths, or make sure you don’t have any caching plugin (like Super Cache) activated at the moment. If you are like me and want to push every now and then the changes to Github, you can do (in your local computer):
git remote add public git@github.com:bernat/blog.bernatfarrero.git #In my case
git push public master
You can do that every once in a while. In case you don’t want to push all commits to Github because you are shy to show a zillion of irrellevant changes, what you can do is set the Github repository as origin and the other as, say, deploy. Every 10 commits or so, you can do (in your local computer):
git rebase -i master~10
pick A
pick B
pick C
pick D
replace all the pick by squash (except for the first one) and then give it a nice message name. This way you assemble one big commit with the changes of your last ten commits. Then, to push it to Github, you can do:
git push origin master #In case you set Github remote as origin
This way you will push a bigger and more controlled set of changes to Github and only after a while. In the meantime, to see your changes in your actual blog you would just go
git push deploy master
Tags: gittwo remote repositorieswordpres githubWordpresswordpress theme
4 Comments »
When you’ve got a designer that often makes awesome but heavy PNG designs (I’m talking about 400K-700K for background images!!) you really must get moving if you don’t want your app to take ages to load. I just found something that helps (of course, you still need to talk to her anyway) but doing this won’t harm:
Get the program pngcrush.
#For Linux
apt-get install pngcrush
#For Mac !Get first Macports*
sudo port install pngcrush
* MacPorts
As the name suggests it will crush your PNG images to a smaller size. It won’t do miracles but it will make your loads lighter. The query I found to get most satisfactory results is this one:
pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB -brute originalFile resizedFile
I did a script to make this automatically for all files, take it if you want:
./reduce.sh
#!/bin/bash
crushed="crushed_"
for file in *.png
do
dest="$(echo $crushed$file)"
pngcrush -rem gAMA -rem cHRM -rem iCCP -rem sRGB -brute $file $dest
echo -n "Crushing $src ... "
done
read -p "Files crushed\n Overwrite original files? (y/N) "
if [ "$REPLY" == "y" ]
then
for crushed in $(ls | grep crushed_)
do
original="$(echo $crushed | cut -c 9-)"
mv $crushed $original
done
fi
Execute this script (remember to do chmod +x first) in your images folder. It will let you check the files before overwriting them. If you are happy with the results, type ‘y’ and the lighter PNG images will replace the old ones.
Tags: compress pngspngcrushreduce sizesmaller website images
2 Comments »
I’d say one of the most common aims of an application is making it self-sustainable and self-maintainable. When we deliver the last version of an app, we usually dream of forgetting completely about it. We want to have nothing else to do with that client (unless of course she wants an upgrade, another product, or she refers us to another potential client). Nonetheless, this hardly ever happens just like this. At least not to me (why is that?). A finished project usually means infinite calls and all kind of unexpected sorts of stressing problems.
Most frequently the reason is someone not reading your thoughtfully written documentation, or maybe someone regretting the way some particular functionality works (usually one explicitly detailed and requested by herself in the past) or [and that's my point today], someone simply “forgetting” how to add or format content in their web.
You want to give them the possibility to add content easily and format it so it looks fancy and gives them a sense of self-satisfaction. And here comes why to use some good markup tool. You need to let your users create HTML (from a text input, textarea, etc.) but, indeed, without actually writing it. You don’t want users writing code that will break your layout! Or having them write a special character, malicious coding, like a missed “” or anything likely to catch you with your pants down and expose any security leak.
The decision to make is thus whether to use the fanciest WYSIWYG (What You See is What You Get) editor with a full set of MSWord-like buttons and labels, or else just a markup language that will magically convert content from plain to html on submitting. After many years of improvements and fights between markup languages and WYSIWYG editors in my opinion only the following remained standing:
Markup languages, editors and gems (and its links):
After having used many of them, my personal preferences are TinyMCE for users that need to make a great deal of formatting to content (last time I implemented it was for a school web interface). It gives them a full set of tools and buttons that allow virtually anything to be done. Besides, it is awesomely simple to use, and even more simple with Rails. Of course, you are always bonded on having users with good taste. For a more professional or technical environment, for instance, a project management tool, I think Markdown language works just neat. The best WYSIWYG editor for markdown I believe is wmd, which I happily discovered not long ago and have been using in my last projects. It’s sleek and unobtrusive, and it lets coexist PRO people, that enjoy writing straight markup (or down, in this case), and those who simply prefer selecting lines and pressing buttons (and leave alone their mental caches). I never understood those people that hates helper bars for markup as a dogma, why shouldn’t people be allowed to press buttons instead of memorize codes? wmd is a one-fits-all!
Tags: bbcodeblueclothckeditorhammerhtml editormarkdownmarkup languageredclothruby on railstextiletinymcewmdwysiwyg
2 Comments »
