Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

New Feature Idea - Templated HTML Editor

edited September 2012 in Framework

I've been thinking a bit more about an idea I have had for awhile, just trying to figure out how to implement it. This kind of goes along with the inline editor we are trying to figure out. I personally feel right now elefants weakest spot is the editor/page editing, and I want to fix it in a way that is powerful but simple and elegant.

A lot of the stuff I write for clients, ends up being somewhat html heavy in the body. As much as I try to abstract away the need for them to understand any sort of HTML, there is no way that they can produce high quality body content without breaking into the code <> on the editor itself.

Solution: If I were able to provide something like a "Template Block" that they could select from a menu and drop in to the editor (Even drag and drop possible) with provided easily editable fields, I think that would be killer. Abstract away their ability to break things, still allow them to produce high quality content.

<!-- start three columns template-->

        <div class="oneThird">
            <img src="{{ image1 }}" style="width: 100px; height: 100px; ">
            <h3>{{ title1 }}</h3>
            <p>{{ description1 }}</p>

        <div class="oneThird">
            <img src="{{ image2 }}" style="width: 100px; height: 100px; ">
            <h3>{{ title2 }}</h3>
            <p>{{ description2 }}</p>

        <div class="oneThird last">
            <img src="{{ image3 }}" style="width: 100px; height: 100px; ">
            <h3>{{ title3 }}</h3>
            <p>{{ description3 }}</p>

<!-- end three columns -->

Thoughts? Any sort of interest in this?



  • edited September 2012

    I think this could potentially be a good extension/replacement for the "Embed HTML Code" dynamic object. I can see a larger editing area (perhaps with syntax highlighting) and a field to give that template a name. Embedding HTML could then be done by choosing an existing template from the list, or entering new HTML to create a new template.

    The trick will be the editable fields. I had a similar feature in Sitellite years ago, but we just put text like <h2>TITLE HERE</h2> in it so they could edit it once it was added into the body. But that makes it really easy to make mistakes, which limited its usefulness quite a bit.

    Handlers that are added to the Dynamic Objects dialog have a list of parameters, including input validation, which would be good to bring to this too. Perhaps the editor could detect {{foo}} tags in the HTML body and let you define labels for them underneath that would turn into separate fields to enter the data into in the HTML embed dialog? Something like this, for example:

    HTML template dialog mockup

    We still have the problem of this only supporting text inputs and no input validation though. Providing a bit of type hinting in the tags themselves, e.g., {{birthday:date}}, would work for some, but not for things like selects. So that's probably too limited of an approach for that...

  • Hmm. Close to what I was thinking, except I was going to go a little bit different.

    The developer could plug in the template as I showed above, but then the user would just selected the template and be provided with the fields to fill in, in an already laid out in the page with html pre-rendered.

    I don't particularly care about input validation, I will leave it up to the user with flexibility. Whatever they put in is exactly what will show. I know at least for my clients, it's much easier to visually edit and know it won't break. They would be willing to give up a bit of flexibility for that.



  • edited September 2012

    Hmm, it sounds like as a first step we could add the ability to add custom buttons to the WYSIWYG editor. Then these sorts of things could be done as apps with minimal core changes.

    I like the idea of showing the templates more visually too, since text and HTML don't give ordinary users much sense of what they'll see in the page.

    How about something like this to extend the editor: Any app that wants to add buttons creates a conf/wysiwyg.php file with something like this:

    ; <?php /*
    tooltip  = Templates
    include  = "/apps/templates/js/wysiwyg.templates.js"
    callback = templates_callback
    icon     = "/apps/templates/pix/icon.png"
    ; */ ?>

    It could then glob('apps/*/conf/wysiwyg.php') for all the custom buttons and add them to the editor in apps/admin/views/wysiwyg.html. For each one it would really only have to do the following:

    1. Call $page->add_script() with the include.

    2. Create a button like this:

    '{{name}}': {
        visible: true,
        tooltip: '{{tooltip|__}}',
        icon:    '{{icon}}',
        exec:    {{callback}}

    That ought to be enough to let any app extend the editor as it needs.

  • I see that being a good start. I see the feature being much more effective with integrated front end editing.

    I might try to play with this feature after I have the admin icon menu in a place where I am happy enough with it.

  • Do you mean editing beyond the wysiwyg editor? Within the wysiwyg editor this should be enough to do pretty much any kind of plugin for it, since most of it comes down to what's in the included Javascript anyway.

    Either way, I look forward to seeing what you come up with, and if the above isn't enough to write the kind of plugin you're talking about, maybe we can make the configuration a bit more flexible if we need to.

  • What do you think about this idea (in addition to the above) I used {! blocks/index?id=[id] !} in my Layout and get the edit buttons right next to tu block. Maybe there could be editbuttons rendered next to any Dynamic Objects or apps. This way there would probably be more Layouts, but editing is very comfortable. Another approach could be making the Page Adminpage more dynamic, according to the apps placed in the Layout. (eg if you have a slideshow App in the Layout there will be a selectbox for the folder Added automaticaly )

  • edited September 2012

    @jbroadway, Yes, I am thinking beyond the bounds of the wysiwyg, because the wysiwyg is just a bit underpowered in terms of usability and rending out elegant pages. It's great if a standard user can only type in one little body block, but I find then all the pages look generic and boring. However, adding a button to the wysiwig might be able to pull this off. I'd have to delve a bit further into it.

    betaman is onto the idea I have a bit closer. Although instead of edit buttons, I am thinking more of a outlining of editable features, with a mouse click to enable editing "fields" to reveal themselves.

    The general concept of defining layouts and blocks is from an old CMS I used to put people on to force them to not break my layouts:

  • Ah I think I see what you mean. So basically defining regions of the template based on tags that you've added to it which get replaced with an inline edit option when clicked? You could build that in the current system with a handler, such as:

    <h1>{! editable/text?label=Title&default=Page Title !}</h1>

    This handler could generate everything necessary to turn that into an ajaxified text input using something like Jeditable.

    I planned on doing something similar with blocks, with an icon that lets you edit a block right in the page with a slimmed down wysiwyg editor that's sized to fit in the current layout while editing.

    But I agree there's room for more than just clumsy wysiwyg-sized editable areas within the template, ones that could be combined to make complex editable pages without breaking the layout. Perhaps extending the {! blocks/my-block-id !} to something like {! blocks/my-block-id/text?label=Title&default=Page Title !} Would that work?

  • edited September 2012

    Close. But. Blocks are not specific to a page, at least I tend to use them as sitewide elements. (footer elements, contact info, etc)

    I want something where they could create a new page, and if it has those template blocks defined, they are unique to that page.

    {! blocks/my-block-id/my-page-id !}

    But the page I'd would automatically be assigned based on the page its on. So you could have for example a one, two and three column generic template page layout the user could select from. (note: this changes a bit from what I have been talking about, but feature wise it's almost accomplishing identical tasks). They would be presented with the relevant number of input boxes. Hopefully this weekend I will find sometime to prototype this so I can explain it better.

  • edited September 2012

    Hi Guys,

    I made a Restful Api for a SinglePage Website. I assume I have a block on every Page wich is referenced by {! blocks/index?id=[id] !} (just because it is already working :-) But if there would be more flexible ways that would be great...

    {! blocks/my-block-id/my-page-id !}

    {! blocks/my-block-id/slideshow?path=myimages&defaultPath=homepage !}

    Is this going in your direction..

  • Your method works assuming you use a new block for every page. Which is fine, particularly for a smaller site. My method would remove the need for repitition. One "template block" would be unique content, same structure across every page.

    That being said, I need to build a one page site on top of elefant. Seems to be popular right now, and I'd like to be fimiliar with it so I can help people better.

  • Just to add a note to the discussion, blocks can currently show one for all pages or separate blocks for each page like this:

    <!-- show on all pages -->
    {! blocks/my-block-id !}
    <!-- alternate syntax -->
    {! blocks/index?id=my-block-id !}
    <!-- show a separate block tied to
             the page id in this position -->
    {! blocks/index?id=[id] !}

    So we could use blocks to achieve the same effect, but still be limited to a blob of wysiwyg text in that space...

    {! blocks/index?id=[id]&type=text&label=Title&default=Page Title !}

    That could create a single line text block so it shows a unique block on each page. When clicked to edit, we could show a text input field with label "Title" and default value "Page Title". However this is still bound a bit too closely with the page ID, so you'd still need a way to differentiate blocks within the page...

    It's also probably a bit too rudimentary for what @shortj is talking about. It sounds like you mean to be able to edit these elements more as a group than individual elements scattered throughout the page. Is that about right? :)

  • Hmm. Didn't know that, so that is helpful, but it appears that this is still bound to a specific page id, rather than allow multiple template blocks with unique content per template style.

    I guess another way to accomplish this would be something like multiple {{ body }} elements per page. And depending on the number of body elements in a page, when selecting a page template, it would change the number of body inputs the webpage editor provided.

    I just need to sit down and code this. :D

  • Perhaps a simpler way would be to create a "body template" property of pages, and make the page editor aware of it. If a body template is chosen, the body field would become a JSON structure like this:

        "template": "my_app/my_template",
        "fields": {
            "field1": "Field value here",
            "field2": "Another value"

    This would happen in the page add/edit forms. Then in lib/Page.php you could render the page body like this:

    if (/* there is a body template */) {
        $body = json_decode ($page->body);
        $page->body = $tpl->render ($body->template, $body->fields);
    } else {
        // ordinary page body
        $page->body = $tpl->run_includes ($page->body);

    Then it's a matter of creating the template definitions (thinking it would need more info than just a template file, for things like input types, etc), and modifying the add/edit forms.

    Just to throw another possibility into the mix ;)

  • i think, thats a great solution. Because its very flexible, and page stays page and block stays block.

    There could be an adminTemplate as well, to specify how the Page Adminpage field Inputs look like (text, selectbox and so on)

    By the way do you know thi editor?

  • It looks a little drupalish though :-)

    How would this look in the Layout?
    {{body.field1}} ?

  • The limitation to my last proposed solution is that you're still taken to a separate page (the page edit form) to make the edits. Even with the inputs in a preview-like render (that presumably replaces the wysiwyg edit field of the edit form), you're still editing out of context.

    But in the main layout templates, the body would still just be {{body|none}}. The body templates would also just have to refer to their internal fields like {{field1}} as in @shortj's original post. But they would still need a way to denote additional properties of each field, and have enough magic to turn the field itself into an editable region. And what about repeating instances of a single tag in the template?

    I was just throwing an idea out there with my last post, but I'd probably lean towards something with inline editing, done either by extending the blocks functionality, or via a custom app that provides a set of tags for layout designers.

    Also to note, tags like this:

    {! blocks/index?id=[id]&type=text&label=Title&default=Page Title !}

    Can also be written as:

    {! blocks/index
        &default=Page Title

    Helps make dynamic tags a bit more readable :)

  • edited September 2012

    "By the way do you know thi editor?"

    ^That right there... phenomenal. Pretty close to what I was looking for in terms of front end.

    And I think the best solutions would be a new app, separate from blocks.

    Sorta random aside but it would be nice to be able to define repeatable regions within a "Template Block" for example

    <div class="tabber-container">   
       {% repeatable %} 
        <div class="tab-box">
          {{ content }}
       {% end %}

    Then it would automatically provide a repeatable region with an add/delete for each option.

  • Good suggestion! I think for my part, I'd like to think on how to make blocks a bit more flexible. I'd like to make it easier to define multiple blocks that are unique per page (fixing &id=[id] with something better), and having a repeating option would be good a good addition too.

    I'm excited to see what you come up with as an inline editing app too! Aloha is pretty slick. I can see a solid alternative editing solution being a popular add-on, or maybe making its way into the core CMS :)

  • Hi everybody,

    I forked the elefant and made some changes to the editor:

    The replacement tags are now replaced by an embededObject-Icon so it looks less techical. On hover you see the original replacement text.

    If you like to get a login for my page to see the editor in action, contact me. jens (@)

    @shortj: did you try out the aloha Editor?


  • Hello everybody, I liked the discussion and I think also try something similar.

    Well, I'm trying to find a solution for this type of editing, to final customer, long time, but still could not enter it, and probably will have to develop.

    Some solutions I found are: The editing interface is very beautiful, I found it very easy even using terms that end users do not understand how "h1, h2" ... But the method of editing within the content and get an instant result is phenomenal, it's exactly what I want. But in this case found that "cms" very limited and subdued, and the code is essentially "closed" because it is compiled, at least what I saw = P

    This is another one that came next: the editing interface of the front-end is ugly, it is true, but it offers more options and more dynamic "content", it is also easy to edit, but I thought the "callback" late, and have not had much time to look at the code completely and understand some important factors.

    Well, these are examples of front-end issue that I think comes closest to the thought of you, and mine too.

  • The sitecake page is pretty impressive!

  • SiteCake has some really cool inline editing ideas. Thanks for sharing those! I would definitely like to see a similarly elegant inline editing option in Elefant down the road. I think we've got a good core which is important to get right first, and we can add this sort of thing on top.

    Another wysiwyg editor I've been looking at is Redactor, which has a really nice API for implementing inline editing, among other nice features. Unfortunately, it's $399 for their OEM license that would allow us to bundle it with Elefant, which is pretty expensive. Maybe there's a way I can fundraise for that at some point...

    @betaman, I really like your idea of using a nicer looking tag for the includes. An image is good, but maybe we could use a larger graphic, something like this:

    In order to do that though, we'd need to include the name of the handler (e.g., "Image: Slideshow") in the output somehow. Perhaps if the embed code was moved to a data-embed attribute and the title attribute was given the name of the handler, we could style it accordingly with some CSS.

  • I would like to do something like this as well. I was thinking to add an icon-path to the conf/config.php and show that icon (if its defined). But putting in some individual appearance makes replacement harder. But I will try to find a solution for the text, icon and the 100% display...

  • I already knew "Redactor" really very good, but very expensive initially. The problem of raising fund for him I can fix, I could give a donation for this, but I wonder if it costs cheaper and would not develop a better editor of your own?

    Sitecake really has a way of edicação beautiful, but I think we can do something better, more dynamic, because Elefant offers more possibilities, as you said "we have a great nucleus," we just need to add our ideas on it.

    I imagine so, as Elefant core, an editing bar at the top or on the left, with the icons of "content types" for the user to drag and drop within the site, and this would imcorporado immediately, and would have an instant using redenrização css template, as in sitecake, and when clicking on text to edit it so it would be equal to the editor.

    Well, we have core versions, the database also backbone.js too, really just make this effect of drag and drop and edit content directly on the live site. Remembering that this version would be just an alternative version of the Elefant, he would have another issue with backend normally, if you like.

    This part of the front-end interface I can help in the development, because I'm really good front end, not the back end. We use bootstrap course, an example of the interface that quickly made ​​with bootstrap: All pages: 20from% 202012-10-24% 2011% 3A44% 3A27.png Edit Page: 20from% 202012-10-24% 2011% 3A43% 3A58.png

  • Both of those are pretty cool. Looks great for novice type web designers or people who want to build their own sites.

  • I was playing around with the embed CSS based on @betaman's fork and came up with a rather easy way to make the embeds look nicer:

    Here's a preview:

    As for Redactor, I'm definitely not sold on jWysiwyg long-term. While it's still actively developed, its API is not great nor very well documented, and has some pretty unintuitive dialog choices. Redactor would be a big step up, and would also be easier to do inline editing with as well. I've confirmed with Redactor support that a one-time $399 fee means we're allowed to embed Redactor in the official Elefant releases, with free updates for life.

    So how about this: There's a Pledgie account for Elefant. I put $50 in myself today and there was $10 from a previous pledge. When it reaches $399 (however long that takes), I'll use it to buy an OEM license of Redactor, at which time we can begin integrating it into Elefant as a replacement for jWysiwyg.

    What do you guys think of that idea?

  • edited October 2012

    I really liked the idea! It really showed commitment to evolve Elefant CMS. I'll help too, this week without fail. It will not take very long to get $399, I guarantee.

    But the method has shown that you are currently using is not exactly what we're talking about, I think. For add blocks into the editor, then continue editing the content for the back-end. very cool, of course, we can create multiple blocks and simply add in the content, is an advance on what we have. But the second example I gave, CMS Express, but it is what comes close to what I say.

    I will complete this project I have on hand, then I will make my donation to Elefant and I will also devote time to try to develop this interface editing what I mean.

    Another thing, I know that many know the Bootstrap (, but you will come to bootstrap development using Joomla? Yes, compare Joomla 2.5 with Joomla 3.0, the interface was polished and very consistent, although Joomla = P. ..

  • Very Nice. I donated something as well :)

    You could use this to check if an icon is in the handler folder of the app <img src="/apps/blog/handlers/headline.png" onerror="this.src='/apps/admin/css/admin/dynamic-icon.png'" />

  • sorry, i just now saw, that you were using the image in css...

Sign In or Register to comment.