In February I wrote a blog on Open Source and WordPress theme and decided that I will submit a theme to WordPress.org. And now I am back with another blog on my WordPress theme Kafal. It’s a pleasure to inform you all the readers that my theme passed the review process and accepted in the WordPress.org repository. Theme ‘Kafal‘ is now live and have been downloaded 1500+ times and currently active on 200+ blogs/websites. I am that much happy about it that every day at least 5 times I check the theme details in WP.org.

It was all started in February when I don’t have much work besides my academics. At that time I was craving for the work. Then after a lot of research, I published the blog on Open Source and making a theme. At that time I was already a member of WordPress slack. I think slack is the best place to start your journey. In this blog, I’m going to share my experience, what I’ve learned during this period.


Coding Improvements

I started my HTML career with <!Doctype html>, which means started with HTML5 but never understand what the difference between the HTML 4 and HTML5. In this theme, I’ve used new semantic elements from HTML5 like headerheaderfooterarticlemainaside etc.

WordPress provides many APIs and I’ve used many of them. This time what was new for me is the Theme Customization API.  Added live preview option for custom options like ‘Header Color’ and ‘Blog Title & Tagline’ etc. That’s a cool API for designing good UX for theme users.

Previously while developing a theme I’ve never bothered on using escaping and sanitizing functions. If you check my first theme ‘Makes me Wonder’ that I’ve created in my second year, I’ve never used any escaping function. Or if I’ve used it then it must be a code that I’ve copied from SO or codex. But now whenever a code that involves DB or User inputs, the first thing that comes to my mind is escaping and sanitization of the data. Writing a poor code with less security can lead to an XSS attack to the site.

I have learnt much more things about the coding style, that I can’t recall at this time but I will surely share them in future.

 

Theme Customization API and Bootswatch themes

Created theme repository named ‘Solitude‘ and started working on it. I wanted it to be like the best of its type. And started designing the theme. I am a great fan of Bootswatch, as they provide cool themes for the Bootstrap. I wanted to create a theme that you can change the theme variant with these Bootswatch themes. So I downloaded different Bootswatch themes and integrated them into the theme with the Theme Customization API. You can change your bootstrap theme with the different variant of Bootstrap. But due to lack of design skills and other works, I stopped working on the theme ‘Solitude’. This theme has more options but it lags in design and has a poor coding style. I will work in this theme maybe in future.

 

Using _s (underscores)

After ‘Solitude’ it was a leap of 2 months when I started again working on the theme. This time with more enthusiasm, more energy. But when it comes to writing the same code again just for scaffolding it’s kind of a heavy task for me. So now this time what I did was, I forked ‘_s(underscores)‘ the starter theme created by Automattic for hacking. Created my own branch and started hacking the theme.

By the way, I’ll not prefer using _s if you are just starting out in WordPress and don’t know the basics.

 

Using basic testing methods & build tools

I wrote a blog on Integrating Travis CI with WordPress Theme. Using build tools and CI(continuous Integration) is must for the projects because a single human error can be a huge problem. So we teach machines to check our code and warn us about our mistakes. I’ve used Travis CI to test my theme, if it is passing the WordPress coding standards or not. There are also some plugins that can test your themes with the WordPress coding standards like ‘Theme Check‘.  These tools will help is making a good theme with Coding Standards.

 

Various Open Source Licenses

When I first submitted my theme on 19th June(Trac ticket), the ticket closed 2 days after that on 21st June. That was a quick review by one of the theme reviewer team lead @poena. The theme got rejected because of having more than 5 different errors. The first and most important error was declaring the license of the theme.

I was aware that for uploading to WordPress.org the theme should have an open source license GPLv3 or compatible. But I haven’t declared it. By saying theme I also mean the assets used in the theme like images, libraries etc. You can check the conversation over the ticket and check all the links she provided about theme development.

For learning about the licenses choosealicense.com is a good source.
 





 

Setting Realistic Deadlines

Without a deadline, a side project may become garbage because it will never be completed. What I learned is that setting a realistic deadline increases the productivity. Be it our assignments, project reports etc. Even we start studying just before the exams. Moving out from the comfort zone, doing the projects that you love & stop procrastination. I have also set a deadline for the theme and yes because of that I have a commit in git with ‘Hackathon’ (check the dates) 😛

Hackathon for Kafal
Hackathon for Kafal

 

Everybody wants to help you just ask

I am not an active member in WordPress Slack but I often open it and read the conversation happened. I always learn something new every time I open it. The volunteers always try to give you the right piece of information even if you ask silly questions.

WordPress is a community that has lots of nice peoples always willing to share their knowledge. If you have any question just ask it and you will definitely get an answer. Want a demo, check the trac tickets 44111 and 44006. 😉

 

Patience

Yes, you read it right Patience. Patience after submitting my theme for the second time, a new ticket was assigned to me. Silence for 2 months. Nothing happened until my theme got on the top of the review. It needs a lot of patience to see your theme on the review queue.

On 8 August finally, @kafleg as a reviewer is assigned to my theme. This time it(theme) was having 3-4 small issues. So I finished working on them and updated new changes. After that, I was waiting for the reviewer’s another reply on the theme.  This time I the reply was this:

Theme set to live
Theme set to live

 

That was an ‘Aha’ moment, I was like telling everybody that my theme got selected and check out the link and email. I am very happy to see my theme on WP.org.

Rivers know this: there is no hurry. We shall get there some day.”

A.A. MilneWinnie-the-Pooh

It sounds awesome when you think that lots of users are using your theme. The piece of code we have written is worth something. Giving back to the community, is it what is Open Source is all about?


Now the happiness is, seeing the badge of Theme Developer in My Profile.

 

Profile Shubham Pandey WordPress
Profile Shubham Pandey WordPress

 

Have any views about this, please let me know in the comment section.

Thanks!


We can't buy Time

  1. I just want to mention that you could have used those 2 months waiting to get to the top of the queue to make fixes, and to review the themes ahead of yours in the queue to speed things along.
    There are plenty of resources that say how to write a theme that will pass a review. The reviews would go faster if authors would read the requirements before submitting their theme.

    1. Yes Joy, in that time period I was also learning about the process and fixing the theme as well. You have also posted some feedback over the ticket.
      Like I mentioned only 2-3 small issues were there for fixing on the final review. And yes every theme developer should have to read the theme requirements and then start coding the theme so that queue will clear up faster.

      Thanks for sharing your opinion.

Leave a Reply

Your email address will not be published. Required fields are marked *