GSoC – Week 15: When everything's complete and done!

This is the final week of Google Summer of Code 2013, all the submissions have already been made and the final evaluations are well on their way. So, this is my last GSoC 2013 update and I plan to use this post to display the final result of what I’ve been able to achieve this summer.

Here are a few screenshots of the app that I’ve taken using the Geeksphone Keon developer device for Firefox OS, which roughly cover the primary features of the app:-

WordPress for Firefox OS - Login Screen WordPress for Firefox OS - Posts List VIew WordPress for Firefox OS - New Post WordPress for Firefox OS - Successful Post Notification WordPress for Firefox OS - Post Draft View WordPress for Firefox OS - Sliding Menu Drawer WordPress for Firefox OS - Pages List View WordPress for Firefox OS - New Page Screen WordPress for Firefox OS - Page Published Notification WordPress for Firefox OS- View Site Mode

At the end of the summer, I would like to state that I’m actually quite satisfied and happy with the way the app has turned out to be so far, given the time-limited scope of GSoC. However, I would like to continue work on the app beyond the GSoC timeline and see to it that the app goes forward towards a matured v1.0 release sometime in the near future.

I would also like to express my heartfelt gratitude and thanks towards @aerych, who has been my mentor for this project. He has been an exceptionally good guide for me throughout the summer and always helped me whenever I’ve faced challenges or felt stuck during the coding period. Also, I would like to express my thanks to the WordPress and Google Summer of Code project coordinators for giving me the opportunity to work on developing the WordPress app for Firefox OS. Thanks a lot to everyone! 🙂


GSoC – Week 13: Almost there!

Deadlines are here!

It’s almost time for final submission’s and I’ve been spending a lot of time lately polishing the code and trying to make sure everything comes together in a neat way. However, there is still quite a good amount of work left for me this week, which I guess I should be able to complete. The good thing is the frontend of the app is almost ready with a few minor styling touches left here and there, which means that the major portion of the coding is done. However, there still is the issue of getting the backend to work properly with the frontend.

Documentation Woes

I’ve been working on getting the app to work with live data fetched from the WP servers via XML-RPC requests using enyo WebServices however, so far, it has been quite an uphill challenge for me as I’ve been unable to find any good documentation so far on getting the APIs to work with WebServices. The only documents that I’ve been able to find so far are a list of XML-RPC APIs for WordPress which however do not have any usage examples to work with, meaning I’ve to manually do a bit of trial and error with each of these get to understand how to work with them better. This has been taking up a lot of my time in the last couple of weeks which has been a bit troublesome for me.

However, the good thing in all of this is that I’m getting to learn a lot of things the hard way around, which means that I have a better understanding of how things work and how to implement things better. Also, my mentor is super helpful at times when I think that maybe I’m slacking a bit. I was a bit worried about how to make batch requests from the client to the server and couldn’t quite understand how to use system.multicall, [again because of lack of good documentation] so I sent him an email, and voila, he again rescued me by replying with quite a thorough explanation of how batch requests work! 🙂

Anyways, to summarize things I would say that all the offline components are ready to go and done, the only thing that I’m still working on is completing the XHR requests to the server via the WebServices. It’s still pretty nascent, but looking at the present status of work, I’m sure I can get it done within the deadline! 🙂


GSoC – Week 12: A week full of Background Studies

A Sudden Break From Coding

After quite a long time, since the start of this year’s GSoC this was a rare week with me spending most of the time researching and studying various ways of tackling XHR requests via Enyo.js in a way that’s compatible with Firefox OS. Essentially, I had to study quite a bit to understand how exactly Web Services work in Enyo and what are the various implementation options available for it.

Using Firefox OS’s systemXHR APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

For this purpose my primary focus has been on understanding how the enyo.WebService component can be used to perform XHR requests for the Firefox OS app. Turns out, that this is quite an easy implementation for Firefox OS. All that needed to be done was to set the app’s permissions within it’s manifest file as follows:-

“permissions”: {
“systemXHR”: {}

Then whenever a systemXHR is to be needed, I would simply add the ‘mozSystem’ attribute to
the XHR instance:-

var xhr = new XMLHttpRequest({
mozSystem: true

This pretty much handles the major requirement for such an app for Firefox OS.

Enyo Web Services

Basically enyo.WebService is a component that performs XHR requests; it acts as a wrapper for the Async subkinds enyo.Ajax and enyo.JsonpRequest, using these subkinds internally to manage HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. transactions. Since the WordPress APIs are XML based, the primary focus here is on using enyo.Ajax to retrieve all published properties of the enyo.AjaxProperties object. Hence allowing direct communications to take place via the app.

Current Work Status

I’ve already completed a significant amount of the background research required for the implementation of the XHR requests for the app. However, due to some unexpected personal problems I expect to be a bit slow at work this week, however, looking at the amount of work left, I am pretty confident of completing a basic working version of the app running by the end of the next week.


GSoC – Week 11: Rounding up the final fittings

Here’s a rather brief report of things that I’ve completed so far [in a very brief words] and things that I’ll be working on in the upcoming weeks:-

How the Car Assembly is taking Shape

I spent the most of last week, polishing, restructuring and moving huge chunks of code to complete the offline framework for the WordPress for Firefox OS app. Comparing the complete app to a car development analogy, what this means is that I have successfully completed most of the body work including the hood, trunk and body. Now the only things left are mounting the engine [i.e. the XML RPC APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to handle XML RPC requests and responses] and getting all the tricky pieces of wiring connected to the body work. This basically boils down to writing an enyo.WebService code to handle and format all incoming and outgoing XHR requests and responses.

Upcoming work to get things connected

I expect to spend most of the time this week studying the WordPress XML-RPC APIs and implementing them on the app via Enyo code. The one thing that I’m sure about is that I’m sure hit quite a few stumbling walls this week as I’ll be again chartering into personal unexplored territories. However, I expect to pick up things quite quickly, once I grab hold of how the XHR APIs and enyo can be brought together to work as one unit and get the app working with live data.


GSoc – Week 10: Smoothening the Edges – Introducing Drawers

Progress this Week

Until last week, my primary focus was on building newer components to make sure that all the primary blocks of the app are in place. However, starting with this week I started putting all the different pieces in their respective places.

My primary objectives for this week were:

  1. Convert the Primary app menu from being just another page component to a sliding drawer component
  2. Modularize the Composer UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. to get rid of the current Scroller layout and allow for more focus on the textarea.

Enter onyx.Drawer!

Onyx.Drawer is quite simply nothing but a simple Onyx control that appears or disappears with a sliding animation, based on a Boolean property.

This solved my primary problem of implementing a sliding drawer menu component for the app. All that I had to do was to change the menu component to a ‘onyx.drawer’ kind, along with few minor changes here and there and a bit of code refactoring, and we now have a sliding menu bar!

The fun part of this came next, when I realized that the same Drawer kind can be introduced within the Composer as well to help me with my second objective of this week. For this purpose, I went back to an earlier version of the Composer with the Settings button in it, and using the button itself as a boolean trigger to open a vertical drawer containing the post settings such as Status, Tags, Categories etc. However, after a bit of messing around with the Composer code, I finally had a much cleaner looking Composer UI with a more aesthetically pleasing looks to it.

Next Steps

This week I plan to work on the last remaining piece of the puzzle: the Login screen! Once it’s done I plan to move on to the backend apis/queries to replace the current hardcoded demo datasets to more real world datasets, sometime next week. Also, there’s a minor bug with the preview module that I’ve been meaning to get fixed for sometime now, that I want to work upon this week.


GSoC – Week 9: A Visual Report to Summarize the Progress Uptil now

Current Status

At the moment I’ve completed work on the base structure of the app, including a basic layout for the Posts, Pages and Comments Views, with a demo data source for each. Also, I’ve a built a basic menu dashboard to access each of the app modules, however, I’m yet to work on the styling part of each of these components.

To give a brief and concise understanding of the progress on the app so far, I’m going with a slightly different screenshot oriented reporting approach this week. Here’s a screenshot based walkthrough through the individual components for the app built uptil now.


Post List

Post List

Posts List

New Post

New Post Composer

New Post Composer

Page List

Page List

Page List

New Page

New Page

New Page


Comments List

Comments List

Dashboard Menu

Dashboard Menu

Dashboard Menu

Remaining Work

The primary things that are left of the work at the moment are a few bug fixes for the Preview module apart from the development of the Login module and completion of the Reader, Notifications, Stats and View site functionalities. Once these are completed I would be focusing on implementing the connections between the app and the WordPress Servers to fetch live data. The last thing on my todo ist is the styling aspects of the app to beautify the look and feel of the app.

P.S.: Due to a sudden internet outage last night I’m a bit delayed in posting this weekly report.


GSoC – Week 8: Bugs and Pages

Those Pesky Creepy things called “Bugs”

Last week went a bit slow due to some unavoidable personal reasons, however, I managed to identify some major bugs that had cropped into the Composer Code. Most of these were basically layout related bugs affecting the general layout at varying device widths, however the two most significant bugs that are yet to be resolved via code were concerning the layout of the WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. toolbar and scroll-ability of the Composer page.

It seems that the best solution for the first problem would be to remove the toolbar from above the textarea and replace it with a floating toolbar over the onscreen keyboard. A few simple CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. tricks should be quite able to take care of this problem.

The second problem is a bit tricky though. Ever since I changed the layout of the composer to a single page layout, the scroll-ability of the page seems to have been disabled. This is most likely the result of using overridden fit-able classes, however, I’m yet to investigate further into this problem. I plan to take on this bug sometime later this week and get it done.

Developing the Pages Module

The next thing that I started with this week was implementing the Pages module. After doing a brief comparison between the Pages and Posts module, it was pretty clear that Pages is pretty similar to Posts and requires almost the same code with a bit of reduced functionality. The way I implemented this was by rewriting the same code as the Posts module with a few exceptions in the Composer functionality, mainly the removal of Categories, Tags, Status and Post Format functionalities from it.

Next Steps

The major work that I will be undertaking this week would be fixing the WYSIWYG and scroller bugs after the Pages module is completed. Once this is done, I would start with a few unfinished functions within the Preview module, and move on to a bit of Styling details.


GSoC – Week 7: Midterms are here – The story so far!

How It All Started and What’s the present Scenario

I got started with the project during the early stages of GSoC by getting myself accustomed to Enyo.js 2.2 which had clearly been completely overhauled from the 1.0 version. For this, I started by developing a few sample apps using Enyo.js just to get the hang of it.

Once, I had become comfortable enough with the basics of Enyo itself, it was time to get started with the real work. I started by looking into the codebase for the existing app and trying to upgrade the code itself to the newer version of Enyo, which to be frank turned out to be futile exercise, as the differences between enyo 1.0 and enyo 2.2 are massive. Hence, the daunting realization of writing the whole app dawned upon me.

At first, this looked like a huge challenge, given the limited time frame of GSoC itself, however, once I got started with it using the Enyo 2.2 bootplate things got much easier. Soon I had a basic layout for the composer ready which was a massive achievement for me as it is most reused component of the app, which is at the heart of all components which is used by the user to post data, like – Posts, Comments, Pages, etc.

The next thing that I started working upon is the Posts list view, which is identical to that of the Android app. A simple scroller with a list of the post titles separated by horizontal lines.Tapping on each title, would show the content of each post. The next thing that I started working with was the Preview functionality. Currently, I’ve a working version of the Preview component working on my local instance, however, it needs a bit of styling modifications to get completed.

In the meanwhile I’ve also worked upon a bit on the styling elements for the app such as the icons and color combinations, however until now they are not a priority of the first order, as getting the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality done is the first priority. I’ve also been actively designing and redesigning the Composer module a lot to make sure that its at par with the peer applications on iOSiOS The operating system used on iPhones and iPads. and Android.

Future Work

Currently I’m working on finishing the Post/Preview/Publish components bundle. This should ideally be complete within the next couple of weeks after which I would be concentrating on implementing the login and stats modules. After this part is complete I would be moving on to the styling part of the application. All in all the project is due for a in-schedule completion.


GSoC – Week 6: A bit of graphics work to add to all the coding.


Continuing my work from last week, this week I made a few modifications to the Composer UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing., to adapt it better to the somewhat restricted 320x480px screen area.

The primary problem with the previous UI was that the Save Draft and Publish buttons for the app, present in the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. toolbar area would disappear out of the screen, due to space restrictions. To solve this issue, I replaced the text based buttons, with icon based buttons so as to reduce the required screen space. I have replaced the preview, save draft and publish buttons with the following three icons respectively:-

Preview, Save Draft and Publish Post Icons

Preview, Save Draft and Publish Post Icons


Earlier, I started working with a set of icons that I had very generously “borrowed” from the WordPress for Android repository. However, one week in and somehow these icons didn’t really looks quite well on the onyx based design layout for the Firefox OS app. I realized that the colors just weren’t bright enough for Onyx.

Hence, I decided to jump into a bit of graphics work and put my old graphics skills to some use. I have come up with a new set of icons [still a work in progress!] for the new layout. Basically these are quite simply a re-creation of the existing icon sets with a matte white finish. As of now I have the following set of working icons:-

Back Icon










Add Post

Add Post


The most reason why I seem to be spending a lot of time fine tuning the new post interface is because, it’s going to be a reusable module, which will be recycled into the New Page and New Comment modules, with small customizations here and there. This is turn means that ensuring that the new post layout is completely done means completing the major portion of work on the Posts, Pages and Comments modules, which is pretty much the bulk of the project. I reckon this should be complete in entirety within the next 2-3 weeks [Posts/Pages/Comments].


This week I have already committed a bulk of the work done to the SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the released code are all centrally managed through SVN. repository other than the previously mentioned bit of work.

The next thing that I’ve started working upon is the Preview module. I already have a basic implementation of the same on my local stub, however, the code is still pretty messy and the UI needs quite a bit of work. For this purpose I’ve begun development of a new Preview kind for the module, which would essentially grab the data off the Compose form and show a basic preview. I expect that a basic version for this should be ready in a week. Also, I reckon this module can again be reused by the New Page module, and most importantly this one can be modified to develop the Page/Post View module.


As per my earlier schedule for the project I have moved on to the development of newer kinds for the enyo source, which means the project is right on schedule at moment. However the completion of more reusable modules means that I would have some extra breathing time to concentrate on fine tuning things making the layouts prettier. If all goes well, we should have a 0.1 alpha of the app ready by the end of August/early September, complete with login, posts, pages, comments and stats modules.

Since the completion of Posts module warrants the completion of Pages and Comments modules in quick succession, the remaining modules: login and stats should be the next major milestones to be completed within September.


GSoC – Week 5: That moment when everything starts coming together.

DEVELOPING THE NEW POST UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.

Picking up work from last week, this week I finally managed to get over the initial inertia that had kept in check the pace of development. To start with I developed the new Compose UI based on the layout of the earlier WordPress for WebOS app, including the base components for the composer, i.e. Preview/Save/Draft/Publish/Settings buttons, headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and footer toolbars, and the layout for a Rich text based WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. editor. Even though the underlying code for the base implementation was surprisingly easy and straightforward, it took me a bit of time to get hold of the whole process.

Long things short, it’s as simple as writing structured object oriented JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. documents once you get comfortable with everything Enyo has to offer.


Once I was done with the basic rework of the Compose UI, the next thing that struck me was the fact that the earlier app was specifically designed with tablets in mind, meaning the earlier sliding layout was good for devices with higher resolution. However the primary target devices for Firefox OS being smaller smartphones, most have a basic 320x480px resolution. Hence, the earlier design layout, would just not fit in the display. Hence, what was needed was a change in the layout.

For this part I’m planning to use the same layout as is used by the current Android app. This would in turn result in two main advantages:-
1. Solve the layout problem for smaller devices, and
2. Maintain a consistent look and feel for the app across varying underlying architectures.


Currently I’ve moved on from the Compose module to other parts of the app. At the moment I’m working on implementing the home screen consisting of a list of the users posts using demo data, as well as reworking the overall design layout for the app. I’m planning on finishing up the base UI structure for the app with open hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. for the various backend functions.Once this is done, I will be moving on to the backend functions for retrieving and displaying actual user data.


As per development schedule I started with the Compose module last week and have moved up to the other base modules this week, which means, that I’m almost back to the schedule as per the initial plan, with only one deviation. I’m primarily concentrating on getting the skeleton for the app ready by the end of this month or start of the next month. Once, the base skeleton is ready, implementing the newer functions should be a pretty simple and straightforward job.