Loading...
 
Skip to main content

Custom Share Module 0.1dev

Themes

Themes

Forum List Topic List

Forums » Themes » HTML input vs Smarty Template. Full Site vs Specific Pages.
 
Thread actions
Print this page
  • Print all pages

    • HTML input vs Smarty Template. Full Site vs Specific Pages.

    Posted by Sam United States

    I'm attempting to build a website for a conference and I'm implementing a design that has already been decided upon. Thus, instead of using a preset theme, I am taking the time to develop my own them and layout the pages according to the design. The group I am developing the website for wants there to be "wiki" functionality, and thus, I find myself working with tiki wiki.

    So far, I've found it somewhat complicated to work with modules through Tiki. While I was hoping to take full advantage of the CMS system, I instead find myself following this tutorial to bootstrap the site:

    https://www.bernardsfez.com/article48-How-to-Bootstrap-a-Tiki

    While it works, the idea of having such a complex HTML input seems to contradict the use of a CMS platform in general. By using such a complex HTML input, the content is no longer easily editable for someone who isn't a programmer. Thus, is there a way to bootstrap more of the native features in TikiWiki? Is this what smarty templates are good for? And does anyone have good suggestions for creating smarty templates? I have worked with more modern frameworks such as REACT and Django, but now I'm assuming I'll need to understand PHP to work with smarty templates? Is this true?

    Alternatively, the entire site I'm developing doesn't necessarily need the TikiWiki functionality. There are just specific sections that will require specific user permissions, allow users to create articles, and allow users to be part of forums. In such a scenario, Should I still try to use TikiWiki for the entire site? Or would it be easier to build certain pages without TikiWiki and use it only when I'm hoping to use Tiki specific features?

    I look forward to hearing everyone's input.

    Sam

    In g

    Reads: 1427
    Posted by Bernard Sfez / Tiki Specialist France

    Hello Sam,

    You made me watch again that Express Video Tutorial I published almost 2 years ago. 😉

    I gave several ways to customise a site design and "not so" complex HTML is one of them.
    All depends of the way you want to work and what you want to achieve. (if your design is complex)

    You can do quite a lot using the wiki syntax and it is always available on screen through your Tiki editing front-end.
    Also you don’t need to "re" design everything and with the use of a few modules and plugins you can give your site a very specific look.

    Where you find limit you can add an HTML plugin to write code.
    IMO this has some limits and for heavily or complex project a smarty template is much more simple to manage, test and write.

    Knowing php is nice to have to work with smarty template but not a must... HTML and CSS yes.

    Posted by Sam United States

    Thanks for the response! I get that the HTML isn't complex, but I'm simply trying to avoid using HTML in the page editor. Ideally that will remain as simple as possible.

    It sounds like the smarty templates will be the way to go. Are there any resources you can recommend for getting started with them?

    Thanks,
    Sam

    Posted by Gary Cunningham-Lee Japan
    Sam wrote:

    Thanks for the response! I get that the HTML isn't complex, but I'm simply trying to avoid using HTML in the page editor. Ideally that will remain as simple as possible.

    It sounds like the smarty templates will be the way to go. Are there any resources you can recommend for getting started with them?

    Thanks,
    Sam


    If you are talking about the content of a wiki page, then Smarty templates aren't involved other than for rare specialized cases. Normally a wiki page's content is plain text plus wiki syntax, WYSIWYG (using the WYSIWYG plugin, for example), or HTML (using PluginHTML).

    For a page like you show in the PDF, in my experience, if I'm the only one who will be editing it or I know the others who will be editing are comfortable editing HTML, then I generally use HTML inside an HTML plugin. You can use wiki syntax like

    Copy to clipboard
    {DIV(class="row")}{DIV(class="col-sm-4")}{DIV(class="card")}{DIV(class="card-body")} Some content {DIV}{DIV}{DIV}{DIV}

    but for layout, I prefer HTML directly especially on complex pages, where standard indentation can be used to keep track of all the sections and divs, etc.

    I did a Bootstrap conversion of a Tiki site a few years ago that's rather similar to your design — http://gecco-2017.sigevo.org/index.html/HomePage.html — which shows Tiki can be used to create this kind of site, first of all. (The organization has been using Tiki for many years and wanted to move to Bootstrap layout when Tiki did; I haven't been involved in more recent years because they have capable people in their organization who can implement new iterations of the site.) Unfortunately, "View page source" isn't turned on, but you can use your browsers DOM inspector to see how the page is put together. It's pretty standard Bootstrap layout.

    Most pages of that site don't need that kind of layout creativity; many are tracker records displayed in wiki pages via tracker plugins. For a page like the GECCO homepage or the one shown in your design, I suggest using PluginLayout to remove side columns and so on, if you want these (like a left sidebar/side column) at the site in general). PluginLayout has quite a few parameters and options to more or less make the wiki content area the entire (or most of) the display port.

    If you have a page that is kind of heavy with HTML layout tags, you can separate the layout from editable content by using PluginInclude. Instead of having the editable content on the page itself, the page contains a PluginInclude for each chunk of content. Then there is another wiki page that contains all the content. PluginInclude can be told where to start including a page's content and where to stop, so these parameters are entered for each plugin. That way one included page can supply all the text, etc. for the including page. That's how this page — https://evoludata.com/ML — is put together. This page — https://evoludata.com/ML_Included — holds the content. Another advantage of this method is that the included page can be translated and the include plugin will include the appropriate language for the particular site visitor. As you can imagine, it's a lot easier to translate a page like "ML_Included" than a page where this text is scattered in a big page of HTML tags, and it's also a nice DRY implementation regarding the layout HTML.

    -- Gary


    Posted by Gary Cunningham-Lee Japan

    Hi,

    With Tiki, themes are only for visual styling and not functionality or page element positioning except for what can be done with CSS. Maybe you could describe in a little more detail the design that you want to implement. Does it require placing page elements in a way that isn't possible with Tiki's default layout options?

    Tiki doesn't need complex HTML input by users or even by site admins, generally speaking. My guess is that if the page you referenced (I haven't read it carefully or watched the video yet) gave that impression, then maybe it wasn't showing the simplest ways to do things, or maybe was showing more complex processes. In any case, it would be good if you can share some details about what you want to do so we can respond more specifically.

    -- Gary

    Posted by Gary Cunningham-Lee Japan
    Sam wrote:

    Thanks Gary,

    As far as I've noticed, there are quite a few page elements that I haven't been able to implement with the basic Tiki dashboard. I do have a full design that I am attempting to implement, and here is a link to a of it:

    https://documentcloud.adobe.com/link/review?uri=urn:aaid:scds:US:face7383-ff52-438f-9fa3-56c89277c265

    I'd love any advice anyone has for getting this up and running.

    Cheers
    Sam


    Hi Sam,

    I hope my previous post was helpful. I would suggest considering the general layout you want for the site overall:

    • Bootstrap-style top navbar or navbar in page, full width vs fixed width, etc. — This can be selected on the Look and Feel admin page.
    • No sidebars/side columns or one on the left or right — This is determined by where you assign modules.

    and so on. Then on the homepage (or any page where you use the full width of the window for content and backgrounds, etc,, you can use PluginLayout to remove what you don't want on that page, for example a sidebar. As I described in my other post, whether I use HTML or wiki syntax for layout (Bootstrap-style grid, etc.) depends on how complex or simple the page is. I kinda prefer HTML syntax for layout generally speaking. Then, using PluginHTML has some advantages over activating the global option to allow HTML in pages (which can be turned on or off per page), so I usually put the HTML in a PluginHTML. Are you ok with creating a Bootstrap grid in HTML? We do have adding a drag and drop page builder to Tiki on the project's roadmap, probably https://github.com/givanz/VvvebJs, but this isn't available yet.

    This kind of layout composing generally isn't necessary for most content pages at the site — it's mostly for "presentation" type pages, I would say. For site member biographies, paper descriptions, association statements, and so on, the standard wiki editor should be sufficient, I would imagine, since it's mostly just adding text and images, etc. without needing to lay things out visually in a unique way. Some content layout is possible with wiki syntax — there's a PluginFluidGrid, I think it's called, which lets you use simplified syntax to create a Bootstrap grid, and images and divs, etc. can be aligned left or right, etc. so there are some limited layout options within the wiki syntax editing environment.

    If there's a type of page that has consistent layout that members will create content for, or a version of, then maybe Trackers are a better way to go. In this case, the information is input by the user into a form and then displayed on wiki pages via tracker plugins. The GECCO site I mentioned earlier uses this for a lot of the content that repeats in form but differs in actual content. I used the "Pretty Tracker" method which is now Tiki old skool — there's a more modern alternative, PluginList that's said to be more efficient but has a steeper learning curve (but go for it if you want to use Tiki's most up to date methods.

    -- Gary