<div dir="ltr"><div><div><div>Hello everyone, this is an update on the website redesign stuff; I know it's been a while since my last update, so I'll also be going over some plan changes.<br><br></div>Mainly I'd like to go over the plan for our existing Capacity pages, and how we can get Wordpress deployed before we have the 'complete solution' to replace absolutely everything we need it to handle. <br><br>The original plan had a "scorched earth" policy where we would just start the new site fresh, along with some custom plugins we would have to provide the dynamic pages we need. This had several issues, and as attractive as a fresh start is... things like dead links, loss of important pages, and the dependency on a robust-and-mature replacement out-of-box has been dragging the next phase of site updates. It required the theme, a page builder, language integration for that page builder, and various other plugins for things like the homepage, applications, and announcements.<br><br>So for the past couple weeks I've been working on solutions going the other way - making Wordpress fit into our current system, and I've landed on something which seems to be workable, with only has relatively minor issues compared to a full-out deployment.<br></div><div><br>The new plan I'm working towards is a Capacity Wordpress theme and a Wordpress Capacity plugin which joins the two together. The aim is to have capacity pages import Wordpress directly, then communicating with a plugin, Wordpress will take over page rendering using the theme layout, settings, navigation, etc. Using some voodoo hacks it essentially turns Capacity into Wordpress when this theme is enabled on a Capcity-driven page. The content rendering is still done via Capcacity function calls, so it breaks nothing, but everything beyond the content is Wordpress driven. That being said, I'm still working out the fineries, there's still some visual compatibility issues, and it requires a patch to Capacity as well which I want to smooth out. If it sounds a bit confusing, here's the essential workflow:<br></div><div><br></div></div><div>1. Capacity page is requested<br></div><div>2. Per-page Capacity config has the Wordpress installation linked (if it's not, nothing special happens)<br></div><div>3. Wordpress is loaded (if failure, Capacity works as usual)</div><div>4. Capacity verifies the Capacity compatibility plugin is active in Wordpress (if disabled, Capacity works as usual)<br></div><div>5. Via the plugin, Wordpress captures the body content and runs it as the output to an otherwise standard Wordpress page<br></div><div>6. Everything is awesome.<br></div><div><br>Eventually, we want to move pages out of Capacity and into Wordpress completely at some point. This, too, is handled by the same theme/plugin combo in development. It might be patched in later as it's a massive hack right now, but using this plugin we'll be able to set redirects within Wordpress as we complete replacement pages; capacity pages should immediately and automatically redirect when superseded this way, and we can even SEO the pages is desired by flagging the redirect. As a special bonus to this, it means that as we replace pages it won't destroy the existing capacity content and the pages will be able to provide a "view legacy content" link - probably by a nice clean URL flag instead of cordoned off folders. Expanding the steps above, step 4.5 is "check to see if Wordpress has content to use instead of the Capacity content, if so, use that". Beyond that it keeps all current workflows intact, so for better or worse everyone gets to keep things as-is until we override the pages directly, and even then reversion will be a simple Wordpress toggle.<br><br></div><div>All that said and done, right now my prototype is super hackish with lots of hardcoded paths, but I've proven to myself that the concept works. <br></div><div><br></div><div>So, this is the "have our cake and eat it too" solution I have at this point. The main downsides I can see with it at this point mostly pertains to a potential performance penalty; every page we switch will have both Capacity and Wordpress run in it. I don't know how much juice our servers have or even if it will make a significant impact, but it means pages using the compatibility layer will have the performance cost of an uncached wordpress page. That being said, this is being done as a per-page toggleable 'switch', so when we're ready to begin deploying it we can enable pages gradually and see if my performance concerns are justified. If performance is an issue we would need to look into a plugin-level caching solution, but I don't want to put the cart before the horse. The next issue is that navigation links and other wordpress-driven page content will not have il8n until a solution is devised, but page content and theme-specific content will use standard translation pot files as we use now which may be fine. Lastly, the live search functionality of the new design will not have a way of searching static pages, but it's a feature we don't have at all right now.<br><br><br></div><div>In term of deployment, the plan is fairly straightforward; <br><br>1. When finished the integration utilities, we apply a patch which enables the compatibility layer on the Capacity level. Pages not using it won't see any impact. <br>2. We install Wordpress on <a href="http://kde.org">kde.org</a>, installing the Aether theme, Capacity integration Plugin, and homepage content plugin.<br>3. We convert the "Aether" pages we have now to use Capacity/Neverland instead of AetherLibs.<br>4. Finally, we add a config line to each Capacity page setting the Wordpress path. This will automatically convert the page to Wordpress/Aether. Minor CSS tweaks and overrides may be required to smooth out content, but nothing too invasive. Everything will become responsive.<br><br></div><div>We can purposefully limit the rollout of wordpress-enabled pages if desired; going from Capacity to Wordpress is going to have some overhead, and we can also limit the exposure of any issues which may need to be ironed out. That being said I don't want a repeat of the initial <a href="http://kde.org">kde.org</a> redesign where I blindsided most of you, so I'll make sure we have a proper review of the changes before anything goes in so there isn't too much 'ironing out' needed.<br><br></div><div><br></div><div>Questions/Concerns?<br><br></div><div> - Ken<br></div></div>