respond

respond copied to clipboard

Being able to switch a site from one theme to another is pretty important to me. I would like to try adding that capability, but I'm not sure to what extent it's even possible. I'm hoping you can give me a little bit of feedback and direction.

One possibility that occurred to me was to store each page's content in JSON format, with subarrays for rows and columns. to make it easier to reflow it into a new theme. Storing the source content is essentially how R5 worked, but I realize it's probably not what you intended for R6. Still, it might make theme switching possible?

Another approach would be to parse the row / column content and convert it to a new grid system if necessary. I anticipate I'd tackle it in three stages:

Stage 1: Add a theme switcher tool in the SPA. It will wipe out all existing site content, and will warn the user of such in big flashing letters.

Stage 2: Program parsing and reflowing of row/column content when switching between themes. If I know the row and column classes for both the old and new themes, it should be no problem to parse out the content from an existing site and reflow it into a different grid system. If a particular template is missing then I will flow the content into a default template. It won't be perfect but it'll at least save the user from rekeying all of their content.

Stage 3: Figure out how to handle theme-specific plugins that are missing from the new theme. Global plugins should work fine without any conversion, but if the old theme had a plugin that is not present in the new theme, I figure I'll just insert it into the new page as an HTML snippet.

Any thoughts on either of the two approaches above? Any giant glaring roadblocks I'm failing to anticipate? Any other approaches that I might consider?

I know you're busy and I don't mean to bug you, but I thought I should try to get your thoughts on this before I start hacking together a pull request on my own. Thanks for any feedback you can provide.

Yeah, this is really difficult going past your stage 1 b/c of the framework issues and the home pages. Most home pages are unique. So, there is often not a 1-to-1 mapping. Let me think about this some more. It would be helpful if you could articulate why this is important. I have personally found that once someone locks in a design, they don't often change it. That is why I have not incorporated this feature into Respond.

I think the main reason to be able to switch themes is for:

• prototyping, when the client is first starting to choose which theme he wants, or you have collected some content from them and set it into the site, you show them a few different layouts with the same content for them to choose
• future change, maybe in the near future they want to change the theme just to keep the site up to date and changing

The type of user that I'm supporting likes to try out a few different themes before settling on one (as do I when I'm creating a site). They may also wish to migrate to a new theme in the future like Joe suggested. Say they've been on one for four years and a new one becomes available that is much more modern and up-to-date. I'd rather give them a way to upgrade in place, than have them create an entirely new site.

I see what you mean about home pages having unique layouts. That may be true of things like Contact pages as well. Maybe I will implement Stage 1 only, or maybe I can create a tool that allows the user to select which pages to convert and which to replace with default content. Perhaps I could even add a side-by-side preview.

I will think on it some more before doing anything. Thanks very much for your feedback.

Hello I would also like to be able to change the theme would be essential for flexibility when implementing projects in respondcms, it would be a good idea to open a markplace so people could create and sell their themes and plugins for the respondcms just as it is today the pagekit project that Even though it was more complete I still preferred the respondcms for several reasons, but it would be amazing to see some features of pagekit implemented also in respondcms.

Switching themes is definitely a priority. But, there are some complications with how Respond works that make this difficult. I will take a look at Pagekit. They have a fundamentally different approach then Respond, but there is definitely a number of things we can learn from what they are doing. I would be interested in hearing your take on the pros/cons between Respond and Pagekit.