Maletschek Nautics - Boat Center at Neusiedlersee in Austria

[bernhard]

https://www.maletschek.at

It's online now for quite a time and my biggest PW-project so far. It has loads of content (sitemap) and the editors are loving how easy it is to manage - client quote: "it's a quantum leap forward"

edit: screencast added here: https://processwire.com/talk/topic/10006-maletschek-nautics-boat-center-at-neusiedlersee-in-austria/?p=95531

Highlights

• shortcut edit-links almost everywhere on frontend with a single line of code in the template file (planning to release a module for this one day i find the time... or if anyone is interested in doing this i can share the code i have so far) and showing what part of the site is going to be edited on mouse hover
  
   
• point of contact for every section - option to inherit it to the whole sub-branch of the tree
  for example "jakob" is point of contact for boats and he will by default also be POC for every single boat posted in this section. if there is a different POC for one single page in this branch (eg /boats/small-boats/) that's also possible by checking the checkbox - so all boats on sub-pages (/boats/small-boats/boat1) will again have jakob as POC
  
  
   
• Caching with custom Cache Reset Module (necessary due to the previous point in the list)
  at least for me that's a highlight because that was the first time i needed to hook something... https://processwire.com/talk/topic/8997-clear-cache-for-all-children/
   
• widget system with complete control of where to display the widget:
  
  in this example the "point of contact" widget is shown an all pages ( site "/" - "show" - "also on subpages" ) except section "blog" ( site "blog" - "dont show" - "also on subpages" )
   
• yumpu online catalog textformatter module like on this page: https://www.maletschek.at/shop/bootszubehor/pfeiffer/
  see forum thread here: https://processwire.com/talk/topic/9888-textformatter-yumpu-embed/

i hope you like it and i'm looking forward to hearing your feedback

and of course thank you all for your help!

ps: sorry, there's only a german version of the website

[Craig]

Very, very nice! And thanks for talking through your approach to some interesting points

[tpr]

Quality work! Just out of curiosity, a search feature was not planned?

[Peter Knight]

The widget system sounds interesting. Any more details there. How is it built, displayed in the Admin and how does it work?

[mr-fan]

1. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/

2. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/#entry83444

regards mr-fan

[LostKobrakai]

Looks really great. One really minor thing: Maybe the logo could be using svg if supported. For me the oblique lines look a little bit frayed, especially as all the other UI elements look clean and sharp.

[bernhard]

Quality work! Just out of curiosity, a search feature was not planned?

it was, but made some problems and other parts were more important. you are right, i think a search would totally make sense and maybe we will ad it one day. thanks for the input!

Looks really great. One really minor thing: Maybe the logo could be using svg if supported. For me the oblique lines look a little bit frayed, especially as all the other UI elements look clean and sharp.

thank you! i changed it to SVG but it's not better. i think that's the fault of the logo itself because in my editor it also does not look very nice? do you see any difference?

 

1. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/

2. https://processwire.com/talk/topic/8635-simple-example-for-widget-management/#entry83444

regards mr-fan

thank you  i'm using pagetable instead of repeaters now because the UI is much clearer and they do not waste so much space. did a little screencast for some more insights - also on the edit-shortcut-links

[cstevensjr]

A very nice website.  Your "shortcut edit-links" really caught my eye in the screencast.  Any additional information regarding those "shortcut edit-links" would be greatly appreciated.

[Pete]

 

A very nice website.  Your "shortcut edit-links" really caught my eye in the screencast.  Any additional information regarding those "shortcut edit-links" would be greatly appreciated.

I'm not sure if this is the way BernhardB did it, but you could achieve those edit links for specific fields with Fredi (watch the video for examples of how to only have a popup for certain fields etc). Also allows for editing of content not specifically on that page, so useful for a widget approach too.

[cstevensjr]

@Pete, Thanks, I'll make some time and take a look at Fredi.  

[bernhard]

hi pete, it's not fredi - it's a quite different approach and i love it i'll go more in detail on this asap

[bernhard]

here you go:
 
it's very simple, yet extremely comfortable for clients. you just need one simple javascript function:

function editLink($pageid) {
    if(wire('pages')->get($pageid)->editable()) {

        // add page if action == add
        // check permission first!
        
        ob_start();
        $editid = "editlink_" . uniqid();
        ?>
            <div style="position: relative;" class="editlink" id="<?= $editid ?>">
                <div style="position: absolute; right: 0; top: 0; z-index: 100;" class="uk-text-right">
                    <a href="/admin/page/edit/?id=<?= $pageid ?>&modal=0" target="_blank" class="uk-button uk-button-primary editmodal" style="color: white;">
                        <i class="uk-icon-edit"></i> edit
                    </a>
                    <?php // next floating button here ?>
                </div>
            </div>
            <script type="text/javascript">
                $(document).ready(function() {
                    $("#<?= $editid ?>").parent().addClass("editlinkparent");
                    // paddings must be adjusted when window is resized
                    $(window).on("load resize", function () {
                        // remove top and right margin
                        var paddingright = $("#<?= $editid ?>").parent().css("padding-right");
                        var paddingtop = $("#<?= $editid ?>").parent().css("padding-top");
                        //$("#<?= $editid ?>:first-child").css("border", "1px solid blue");
                        $("#<?= $editid ?>:first-child").css("right", "-" + paddingright);
                        $("#<?= $editid ?>:first-child").css("top", "-" + paddingtop);
                    });

                    // colorbox
                    /*$(".editmodal").colorbox({
                        iframe:true,
                        width:"90%",
                        height:"90%",
                        onClosed: function() { location.reload(); },
                    });*/
                });
            </script>
        <?php
        return ob_get_clean();
    }        
    else
        return false;
}

and little CSS:

// edit link
.editlink {display: none;}
.editlinkparent:hover {outline: 3px solid #ddd;}
.editlinkparent:hover > .editlink {display: block;}

note that i'm using markup for UIKIT css framework.
 
what it does:
 
let's say you have a blog-template showing all the children as postings. all you need to do when you want them to be editable on mousehover would be this:

<?= editlink($page->id); ?>
<section class="uk-grid uk-margin-left uk-margin-right uk-margin-large-top">

    <div class="uk-width-large-3-4">
        [...]
        <?php
        foreach($posts as $post): ?>

            <div class="uk-grid">
                [...]            
                <div class="uk-width-medium-3-4">
                    <?= editlink($post->id); ?>
                    <h4><a href="<?= $post->url ?>"><?= $post->get('headline|title') ?></a></h4>
                    [...]
                </div>
            </div>
            <hr>
        <?php endforeach; ?>

the result is something like that:

 
note that it needs only 2 lines of code! you can easily add this to any existing website in minutes...
 
in FREDI you have to define your editable fields. that can be an advantage, but i prefer to only rely on the ID of the page (or the posting or the widget...) and have the user redirected to the right page in the backend. as you can see in the commented section of the function i also had this working with a colorbox and using modal=1, but it's more foolproof having it open in a new tab. using only the ID has the advantage, that if something changes with my field settings i don't have to change anything on frontend.
 
how does it work?
 
it injects some jquery javascript inline (it's only for logged in users so that won't affect your "public" markup of the page!)

• add HTML for the edit-button with edit-link
• add javascript
  • add "editlinkparent" to parent DOM element
    this makes it possible to show the border around the affected content on mouse hover
  • remove spacing so that the edit-button is on the very topright position of the highlighted div

that's all
 
again: i would love to pack that into a module so that it gets reuseable across other CSS frameworks with different markup and you don't have to care about adding the function and the css, but i don't know when i can find time for that. if anyone wants to try - all the info is above and i'm always willing to help

[Pete]

in FREDI you have to define your editable fields. that can be an advantage, but i prefer to only rely on the ID of the page (or the posting or the widget...) and have the user redirected to the right page in the backend. as you can see in the commented section of the function i also had this working with a colorbox and using modal=1, but it's more foolproof having it open in a new tab. using only the ID has the advantage, that if something changes with my field settings i don't have to change anything on frontend.

You could use $fredi->renderAll($your-page-id); I think in Fredi to achieve similar?

Either way, I am loving front-end editing whatever the method. Not sure why I'd not looked into it sooner myself.

[bernhard]

didn't know about renderAll() from fredi, thank you! would be nice to have this on the documentation page i thought that you always have to setup all the fields that you want to have edit-access for and i wanted to avoid this work ^^

there's also one major difference: fredi inserts a plain edit link and screws up your design! take this example from the basic profile:

<!-- main content -->
<div id='content'>
    <?= $fredi->renderAll($page); ?>
    <h1><?php echo $title; ?></h1>
    <?php echo $content; ?>
</div>

all the content moves down

i'll bring apeisa in - maybe he can bring best of both together

[apeisa]

I like the idea of adding class into parent element and using that to hide/show/style the hover. I think it will work in most designs, but not all. I'll add that as option into Fredi.

[Pete]

I just didn't want anyone to create unnecessary extra work for themselves unless they really wanted to

[tpr]

Am I right that it generates so many $(document.ready) as many edit buttons are?

Perhaps this could be further tweaked to add the edit id as a data attribute, and use only CSS hover to show edit buttons (using :after for example). Then jQuery should do the rest on a click event. Anyway, just an idea, it may fail somewhere

And do you check the padding size because of the 1px border? If so, perhaps inset box-shadow could solve it.

[Juergen]

Good Job! I like the design.

[bernhard]

I like the idea of adding class into parent element and using that to hide/show/style the hover. I think it will work in most designs, but not all. I'll add that as option into Fredi.

great! looking forward to seeing this, thank you

I just didn't want anyone to create unnecessary extra work for themselves unless they really wanted to

you were totally right - i thought fredi had a different concept. with renderall() that totally makes sense! the day for my first module (that's worth being called a module) will come anyway

Am I right that it generates so many $(document.ready) as many edit buttons are?

Perhaps this could be further tweaked to add the edit id as a data attribute, and use only CSS hover to show edit buttons (using :after for example). Then jQuery should do the rest on a click event. Anyway, just an idea, it may fail somewhere

And do you check the padding size because of the 1px border? If so, perhaps inset box-shadow could solve it.

you are right regarding document.ready - it was more of a quick and dirty proof of concept as it is only outputted for admins but to be honest i don't know if it would be much better to pack all addClass() commands into one document.ready() function than having them inline...

regarding the .css("right") and .css("top"): that's to place the edit-botton on the very top right corner if the parent container has some padding:

[tpr]

i don't know if it would be much better to pack all addClass() commands into one document.ready() function than having them inline...

No need to use addClass at all. You could add 'data-edit-id="currentEditID"' to the parent container itself, with PHP.

regarding the .css("right") and .css("top"): that's to place the edit-botton on the very top right corner if the parent container has some padding:

I see. Setting editor buttons position to absolute didn't work?

[bernhard]

that's the benefit of my approach: you don't have to touch the markup of your parent dom-element. just add one line of code (<?= editlink() ?>) and you are good - regardless WHERE you put it. that's especially useful when you have a widget-system like i have in the example. i have all the widget-markup in one folder and it can be that the first line is <?= editlink($widget->id) ?>. could be hard to find the right parent to add some code via php

with php i would have to add data attributes or classes or such to all the parents i want to be "hovereditable". and you would also have to check if the user has edit-access. lots of unnecessary work compared to 1 js function and 1 php echo for each editlink.

----

it is absolutely positioned, but in a relative positioned div, so that it remains in the current DOM element. otherwise all edit buttons would stick to the topright of the window!

blue = parent DIV

green = relative helper DIV

edit-button = absolutely positioned INSIDE the GREEN helper. due to padding of the blue container it has to be positioned with negativ margins for top and right so that it appears to be inside the blue parent

[tpr]

I'm still not fully convinced about your approach but I'm sure you see a bigger picture than me

Wouldn't such mod work? Just because if you could set the parent with PHP than the positioning issue would gone.

<div class="uk-width-medium-3-4">
                    <?= editlink($post->id); ?>

<div class="uk-width-medium-3-4" data-edit-id="<?= editlink($post->id); ?>">
                    

Of course in the second one the editlink function would return an ID only, not an anchor.

[bernhard]

hmm, good point

most of the time that would work, i think. though there are situations where i simply don't have a parent in my portion of code. say i have a 2-column setup like this:

___________
|_________|
|   |     |
|___|_____|
|_________|

 

and i have a widget like this:

<h1>title</h1>
<p>body</p>

that's all the code i have in my template-markup-file. i would have to wrap this into an additional container, because i don't know if i place it in the left or in the right column! in my case it looks for its parent regardless of wether it's placed left or right (that's defined via backend and stored in the DB).

<?= editlink($page->id) ?>
<h1>title</h1>
<p>body</p>

if you have more of those widgets in one column you would have to wrap them into their own divs anyhow - so both approaches would be quite the same. maybe that discussion is getting a little bit theoretically here 

how would you place the edit-button in your approach? a javascript injecting some code into the dom with the data-edit-id="x", right? wouldn't you also have to adjust paddings in that case?

edit: i like your approach. if you did something like this

<div class="..."<?= data_edit_id($page->id) ?>>

resulting in

<div class="..." data-edit-id="1001"> // logged in
<div class="..."> // not logged in

you would also keep your markup clean!

[tpr]

Yes, my approach would probably result in cleaner markup and I guess more maintainable too.

You can use this to avoid empty data (or class) attributes:

<div <?= data_edit_id($page->id); ?>></div>

I would do an each loop in js to add the actual edit buttons where data_edit_id is available. Plus add the click handlers of course.

This also means that it won't run without javascript, but in the admin it is always available.

[apeisa]

Just pushed version 1.1.0 to github. Please let me know how it works.

I went pretty closely with Bernhard's original css stuff, I also added options to hide additional tabs. Although I have feature detect for touch, when hovering is not required to see edit links.