search

edgeryders / discourse

The discourse.org forum software, with all the modifications as used on edgeryders.eu.
https://edgeryders.eu
GNU General Public License v2.0
8 stars 2 forks source link

Finish implementing static pages #4

Open tanius opened 7 years ago

tanius commented 7 years ago

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:

  1. 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.

  2. 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.

tanius commented 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:

  1. Provide and document a suitable micro CSS framework for layout options on static pages (things like "content in two, three and four columns, with breakpoints").
  2. Provide and document some custom CSS classes for design of static pages that use our corporate identity elements and colors.
  3. If needed: Custom Ruby on Rails template for all topics in the "Menu Content" category.
tanius commented 7 years ago

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.

albertocottica commented 7 years ago

... or we could move all static content elsewhere?

tanius commented 7 years ago

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 …

albertocottica commented 7 years ago

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 .