Open tanius opened 7 years ago
The basic implementation is now done, by choosing the public Discourse category "Help & Feeback → Menu Content" for all static pages linked from the menu, and hiding the forum-typical elements from them (see #32). Static pages are identified by being inside this dedicated category, so there is no need to have the originally proposed, custom /p/123
URL format.
This leaves the following bits and pieces to be fixed within this issue:
Turns out, using a micro CSS framework could be rather difficult as most CSS classes etc. are removed when "cooking" the saved content into the presentation format. (When the user opens the content again for editing, she'll still see the CSS classes.)
However, given than CSS classes are not removed from <table>
tags, and that CSS can also work on tags without classes, it might still be possible to provide the few additional formatting and layout options we need.
... or we could move all static content elsewhere?
We could, but I'm quite strongly against it :slightly_smiling_face:
More software installations, more problems. If people set off to create external sites for Edgeryders projects (WordPress stuff etc.), of course they are free to do so, but it's their own endeavor. There will be no tech support from my side – because inefficient, and does not help our core infrastructure along.
@damingo found a way to whitelist certain HTML tags and attributes in code. Has to be worked out further when we get to it, but there seems to be a way to get a micro CSS framework to work, after all …
Whatever you prefer. Many sites is bad. But so is messing around with code to get it to do things it was not meant to. In practice, making this call depends on specifics.
On 3 Aug 2017 22:00, "Matt" notifications@github.com wrote:
We could, but I'm quite strongly against it 🙂
More software installations, more problems. If people set off to create external sites for Edgeryders projects (WordPress stuff etc.), of course they are free to do so, but it's their own endeavor. There will be no tech support from my side – because inefficient, and does not help our core infrastructure along.
@damingo https://github.com/damingo found a way to whitelist certain HTML tags and attributes in code. Has to be worked out further when we get to it, but there seems to be a way to get a micro CSS framework to work, after all …
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/edgeryders/discourse/issues/4#issuecomment-320074402, or mute the thread https://github.com/notifications/unsubscribe-auth/AB4p5v4g1RR02YNg9fFm6USySjaWTR1Aks5sUibTgaJpZM4N9QRM .
For the Discourse installation on edgeryders.eu, we need a way to manage content that can be reached from the main menu and is presented as a full-page article. So, similar to WordPress "pages".
Implementation options, to be discussed:
Discourse category. There would be one special, access protected category inside Discourse with topics that are set to "wiki" and have comments closed. Company staff can then edit the content right inside Discourse, and when visited from the main menu, it would be shown with a different visual style than the default Discourse content. This rendering logic would have to be custom developed in Ruby on Rails, probably by adding another page controller and view template. URLs served by this could be "/p/123" (using the topic ID). The Discourse main menu plugin would be used to refer to these URLs, and as URLs use the topic ID, renaming a page does not break the menu. Problems: It is unclear if "nicely designed" pages can be created. But probably yes, as most design can be added by CSS. We'd need a toolkit of our own re-usable CSS classes for pages, and a short manual about how to use them. The same applies to layout, where this becomes necessary. It will probably enough to provide a solution for content in two, three and four columns, with breakpoints for narrower screens.
WordPress static pages. This is possible similar to the roots.io / discourse.roots.io site structure: have Discourse on a subdomain, have WordPress on the main domain, and add an identically looking menu to both sites. Advantage: Profiting from nice, sleek, commercial templates to use. As WordPress is multisite-capable, landing pages with an own domain (like current opencare.cc) could be hosted inside the same WordPress installation. Problems: two websites to manage, update, back up and adapt the design on. Two menu structures to keep in sync. Login will be messy (but sufferable) as admins will need an additional WordPress login for editing WordPress pages.