I have got started with a proposal. From my initial understanding of the project, my deliverables ideally would be -
Support for cloning files from another theme in the theme editor
Versioning of theme files through Git VCS
Ability to download & install themes from an external store TTW
Ability to install and update theme via an external Git Repository
Implement code hinting through ACE Editor in theme editor
Contextual help pop-ups within the theme editor
Drag & Drop Theme Upload Support
General UI/UX Improvements focused on Web Accessibility
I am a bit confused about the external theme store. I get the idea that we need to implement something like WordPress theme installer, where it will allow to install themes published on wordpress.org/themes. But in our case, do we have such a place where the themes are published?
Further, should I share the link to the proposal here? I can make mockups of the new proposed designs, would that be useful, or is there existing design guidelines that need to be followed? I am further far less matured with the codebase, and it would be greatly helpful if I get an initial help on locating the various files/APIs associated with the theme editor.
Yes, it will be something similar to the wordpress.org/themes store, which we currently do not have. Therefore, we would need to create the infrastructure and application for the store. I started to develop the application by using Plone/Guiltonia as the backend, but I haven't reached far. I had planned to provide you with the docs and server access for the Theme Store app before you finish the proposal, but I got caught up with work. Therefore, let us put the Theme Store deliverable as a bonus deliverable instead of a primary deliverable.
Let's add this feature as one of the main deliverables. It is more S.M.A.R.T than the Theme Store feature at this point. Do you agree?
Hmmm... that would be better for now. However, it will be really awesome if could achieve that in some point of time.
Yes. Exactly, making themes git repository and thus using git to maintain versions (i.e. each save reflecting a commit), should enable functionality very similar to Google Docs. Since we are making theme folders git folders, we can also have external repository as remotes allowing admins to maintain the theme elsewhere. In fact, git revert/pull/fetch/push could serve us to implement a pretty advanced versioning system. This should be the primary and most useful deliverable of the project.
Here is google doc link to it -http://bit.ly/2HVGUJE. Its a rough draft for now, and I will add mockups and more details by tonight. I hope to add some code references also well in time. Thanks for sharing me the relevant packages, and your gsoc project would serve me an inspiration.
I have set-up a normal Plone 5 application, and I am not sure whether it is the development instance. I will go through the instruction and build it.
I could relate this project with the functionalities of AceIDE WordPress plugin, which I had been using to edit wp themes and plugins TTW. It is an open source project available on github. I think it can be a great starting point for us to get a clear perspective about the theme editor we want, and since its also using ACE Editor.
The theme store idea is very nice, but I wonder if there is a simple way to implement it (ie. not a Guillotina stack, nothing particularly fancy or complicated). I say this knowing how much of a burden even a "simple" server adds. Something file based like Github pages would be perfect
Yeah. Through the project, I intend to make each theme a git repository and one can add themes from a external git repository (git cloning the themes, and maintaining remote for updates). We can make use of this. So, essentially
A theme publisher can publish his theme in something like GitHub/GitLab (and maintain it there)
He submits his theme (with the link to the git repo) with plone (through a simple form)
We can list it in the theme store (maybe even scrape and get details of the theme from github itself)
A user can install the theme from store (we will clone the theme, same way user creates a theme from external repo as proposed)
So essentially, a semi-static website (i.e. with JS and API-fetches) should be able to do it.
What do you think about it? I would love to work on the theme store also through the project
@aswinshenoy, sorry about the last few days.... I was unavailable due to work.
Agreed. The idea generally surrounds making the Theme Editor comfortable and intuitive to code in. Most of what the AceIDE offers in Wordpress, those should be included in the Plone Theme Editor. A number of those features are already implemented.
These are good. Alright, we can plan for what we need to do to pull off the Theme Store; however, I still recommend to have it as a bonus deliverable.
Similar to Theme Forest or Wordprress store, it's an online directory of downloadable free Plone themes, maybe in the near future support paid themes. However, regarding to the number of free theme for Plone 5, there are a lot that are unaccounted for. I know most themes are customer based themes, while others are generic based on the market. I for instance have several themes that I reuse on various projects.I tend to do a lot of fancy Diazo work that is reusable in any project. For instance, auto-collapsing breadcrumbs diazo rule.
I think that the Theme Store will encourage more themes to be created and if there's a space to sell themes, then it will encourage designers and theme editors to create more themes.
@aswinshenoy, I think I failed to point out that Plone has it's versioning and history log for files, content and resources, see History and versioning However, it is not enabled for theme files.
The reason why Git versioning should be implement is due to the fact that we want to combat scenarios where a change is made TTW on Plone and the theme is hosted on Gitlab/Github; the theme would have to be downloaded, unziped and pushed to the remote repo. Also, someone or a CI/CD mechanism can easily override the entire theme, which will result in code lost.
It would be great if it was possible to sell themes (somewhere). It is quite difficult to sell them 'online' and it seems like a google add costs 10€ a click… not really possible to do when a theme cost 250. Could it be possible to link to URLs of 'Premium themes' instead of 'selling them 'in the store' ? Or what do you want from 'theme editors and designers'? I am putting together a demo of some of my themes at http://themes.medialog.no … could it be possible to 'link that' ?
Yep, these requirements sound possible but the payment aspect should not be in the GSoC project. However, it can be marked as a theme for sale with a link to preview the theme. When the store is matured, then we can do in-store purchase of themes.
@aswinshenoy I wouldn't link it to github only. I had a proposal a long time back where a site plone itself became a simple repository for another plone site to browse to pick and download a theme for. This allowed for quick internal distribution of software within an intranet for example. Using github as another respository "source" would also be helpful. The model I'm thinking is similar to kodi where you add a list of repository sources to your configuration and then you can search and browse them to download new themes.
It would be helpful to extend the theme editor with the idea of versions however as it would be hard to manage as versioning in the current theme editor means renaming using any number of naming schemes.
Yes, I totally agree, I didn't meant github/gitlab specifically, but any external git repository.
I thought of a hosted theme store concept something like WordPress, but "sources" concept seems interesting, and that can help us implement it with less maintenance. But I think we will have to define and implement some standards, so that we can fetch details of the theme and provide a very much WP like browsing interface (with filtering and searching).
The idea of versioning is pretty complex, and I am still figuring ways out. I wished to implement somewhat advanced versioning like git, with each file actions forming a commit, and one can use revert to go back. Not sure of the implementation part yet, though.
I don't think managing payments should be our cup of tea since we are primarily an Open Source Org and should focusing on developing Plone. Maybe once our free theme store and the support for uploading themes become stable, and popular, sites like ThemeForest would enable support for Plone Themes for helping our publishers.
I'm really sorry to say we didn't make it this year. Plone was given only three slots for GSoC as a sub-org, and our project didn't make a list.
I hope this hasn't deterred you from GSoC and Plone. You're very talented and would have made a great impact. In fact, despite the result, I would still like for us to work on the Theme Editor. Are you interested in doing so?
I totally understand, in fact, my proposal didn't stand a fair chance, as I was very late. However, as mentioned earlier, I had also applied for GSoC with Salesforce, which I was thankfully selected. So, unfortunately, I am a bit committed to it now I would have loved to work on it, but this being a pretty big project, I don't think I will find time during the GSoC period now.