I always wanted to create a very simple WordPress based Todo App. After putting it off for a very long time I finally had the time to look into it.
The idea was a simple todo list that takes over your WP home page and relies on a standard to do post type for persistence. The interface should be driven by React using redux for state management. The result should be WordPress plugin that simply works without any configuration. The app works over the WordPress JSON REST API and must have a very simple UI framework.
1.Defining the data we need to store:
- user – name and login details. For this, I cheated and simply use the WP login interface.
- Todo item – with the ability to save details on a todo. For this, I use simply used a new post type. The title being the todo, the content being further information and post meta to store the state( completed/not completed )
2. Define the todo post type which we’ll use to store todo items. Each todo item relates to a post. You will notice that it’s not anything fancy but includes a few rest API configuration to make it easy for us to call posts at a later stage.
3. Setting up the JS system. I used Webpack to manage all frontend modules. I used yarn for package management and also Bable to allow me to use ES6 syntax.
4. For the UI framework, I used spectre as it is very light: https://picturepan2.github.io/spectre/
5. For user authentication, I used the user login and then relied on the WP cookie to allow the user to create todos over the REST API.
You can find the source code to play with here, it’s a wp plugin so you can install it:
I attempted this project mainly because wanted learn about all the new frontend tools. I mostly work in PHP and doing this was very refreshing. I’m inspired to do more of these. Even if no one ever needs it, I built it coz I wanted to.
Is syntactic still slowing down your workflow, try A.L.E. It’s a drop in replacement for syntastic ( make sure your language is supported ):
It works with instantly with vim-airline.
This is the only line I’ve added to my vimrc is”
let g:ale_open_list = 1
If you’re using VIM with CtrlP, here’s a tip to quickly jump to line numbers in a file:
I’ve tried many editors, but with each of them, I found a few things I didn’t like. I always knew about VIM and I knew how to exit vim ( link for the pun ), but never thought it serious enough to work in until I saw how magically other people were using it. That’s when I started thinking about trying it out. I’ve been using it for little over a month now and this week marks the end fo the first week of using it at work.
I started googling around for the best guides on where to start. This led me to the book called Practical Vim. This is the only book a beginner needs. It covers all the most important things you need to know. It also gives you a great foundation from which to grow your very own .vimrc.
The IDE rabbit hole
On making the switch I realised that I’m seriously going to miss PhpStorm if I don’t figure out how to use VIM effectively.
Enter plugins, the magical stuff you drop in to give VIM super powers. Then enter plugin managers. The first one I tried was one called Pathogen. It worked like a charm, but then I realised I needed to add git submodules for each new plugin. The thing with vim is that you want to version control all the things so you can easily take your environment with you when switching machines. So I’ve got a plugin manager and I have that under version control, but adding so many submodules was not working out especially after the 5th plugin. I eventually switch to something that only keeps a few strings in your config called Plug.
Side note, if you want the best way to keep your dotfiles on GH see this: https://news.ycombinator.com/iterThem?id=11070797
Now that you have all the vim niceness you’ll soon realise you need a better way to manage the terminal. You need tabs, panes or some sort of split window system. There are many, many options. I looked at a few and decided on Tmux, the main reason for doing so is that it is terminal based and works on many platforms. I’m totally happy with this.
I hear that people use this editor for years and still learn new things. I’ve seen from using it for a month that you’re alway tweaking your workflow. There’s always something new that you can add or change in your .vimrc. The best thing about VIM is that no two people use it in the same way. It should become an extension of your thoughts so that the editor gets out of your way. I’m not there yet, but I can see how my muscle memory is forming day by day.
I can now freely move between machines and take my editor with me. I has dot files: https://github.com/dwainm/dotfiles
In PhpStorm, Cmd + L gives you this magic wand that fixes code indentation a common coding standard issues. I miss it so much. I need to figure out how to do this in VIM.
Another struggle I have now is that I’m constantly pressing the wrong keys. This will probably get better with time. I found that I can use the numbers keys at the top fo the keyboard because I don’t know where keys 4-7 is in the dark. I’ll have to learn this.
Lastly I the struggle is just to adjust to a new workflow. One where I’m constantly tweaking things to better my productivity. I believe this will pay off over time and I’m excited about my new vim adventure.
Often times, one forgets that the tools you and other people use actually have people just like you working hard to ship the nex improved version.
It is quite interesting to see how the developers work to produce such an amazing tool used by many renowned DJ’s and producers.
I have a littles secret to confess. In the days when I was still building client websites I would instal and reinstall at least 5 similar plugins before finding the perfect one. In majority cases I would never let the developer know if there was a bug as I simply didn’t have the luxury of time.
This got me thinking about the code I write today. How many people do that and never let me know what broke and if there was a reason for not selecting my plugin.
I still haven’t figured this out but I take this away from it. If it doesn’t work people walk away. If I don’t get there attention and give them what they need fast. It’s a done deal.
I’ve fallen in love with another text editor. Its been since a while since I’ve last opened SublimeText and Coda. It has also been a little bit challenging to adjust at times but there’s no looking back when it comes to building WordPress based products. My workflow is even better than ever. Now let me tell you why you should love PHPStorm.
PHPStorm understands WordPress
As the the tools name implies, it understands PHP, so what? That’s not all. It actually understand WordPress. It can pick up when you’re running a WordPress specific project and it can make suggestions to enhance your project settings to give you the best setup for getting work done.
Its a purpose built tool
Theres no need for plugins. PHPStorm comes with all the tools you need. If you need more tools it has an ad on system through which you can add more plugins.
Project specific terminal
Every project comes with a localised terminal window so you can start bashing out terminal commands from the get go. All this without leaving PHPStorm. If you love using git from the command line this will be one of your favourite features as it easily buys you a few hours extra per month.
Predefined styling Rules
PHPStorm has the WordPress style guide built in so you can get your project inline with core’s coding standards right from the start.
Never forget that TODO comment
If you like making inline comments to leave yourself notes and then forget where you’ve place the todo items you’ll be thrilled to know that PHPStorm remembers this for you. You can filter this by the entire project scope or just a specific file. With this you can track all your todo items across the project without the need for an external system.
Debugging made super easy
No more need for var_dump and echo to find bugs. All you need is to turn on xDebug on your server and link it to PHPStorm. From this point further I guarantee that you’ll speed up finding bugs in your code. This is the main reason for switching over. If you’re still figuring out where your bugs originate without reloading the page and checking the var_dump. Switch over today.
- Using PHPStorm: https://confluence.jetbrains.com/display/PhpStorm/WordPress+Development+using+PhpStorm
- WordPress support in PHPStorm:
- Debugging: http://thehungrycoder.com/tutorial/wordpress-debugging-in-phpstorm.html
At this point in my life I am happy. I have a relationship with my heavenly Father through Jesus. I have a loving wife with who’m I’m excited to share the rest of my life with and together we are working towards common goals.
This blog post will serve as the official starting point of my Journey. I publish this in faith as I believe there will be others asking me about my journey and how I made and and i’d like to share my ups downs and what I have done but more specifically the mind set behind my success as a Software Engineer. Continue reading Start your Journey now
Your project is going absolutely great. You’re committing regularly and you’re getting close to the release date and then you that the is a (CONFLICT).
You see something like : file.extension : needs merge ,?
Then you google ans see that opening a merg tool will help and then suddenly you’re dumbstruck and you can’t even move.
The first thing I wanted to do was to the heck out of there.
Press “ESC” then press ” : ” after that enter ” qall! ” , after this make sure to selecet no when you’re prompted with “Was the merge successful? [y/n]” . Unless you’ve fixed it select no.
Secondly, what’s up the 4 windows? Please not the descriptions below are not in order 1,3,2,4:
1. The target branch, which is the one you’re on now. This is where you would like to merg the other branch into, but this window is only used as a reference to see what the current branch looks like.
3. The remote/merge branch which is the branch that you would like to merge into the local/target branch above (1).
2. The most common ancestor of the target (1) and the merge(3) branch.
4. The final branch into which you would like to merge the target and the merg branch. This a computer generated file into which the most common items is merged but this is where you need to pull items from target (1) and merge(3) into, to give you the final file.
Now the first thing you should note about the four windows is that you can have the cursor in any one of the four and work from there. To move the cursor around you press:
‘CTRL + W’ ‘ CTRL + W’ (press it twice)
The second thing you would like to do is move from one conflict area to the next.
‘]c’ (right square bracket ‘c’) move you to the next conflicting text
‘[c’ (left square bracket ‘c’) moves you to the previos conflicting text.
:ls identify the windows (names and numbers) This is important so you can combine it with diffput and diffget commands below.
:diffget * diff get takes a change and brings it into the current working window. It is important for you to use this with the identity that you find when running :ls . You can also use ‘do’ as a shortened version (without the colon)
:diffput modify another buffer from the current focus area.
I’ll add more and change this cheat sheet as I discover this tool.