Jump to content

Maletschek Nautics - Boat Center at Neusiedlersee in Austria


bernhard
 Share

Recommended Posts

post-2137-0-68528000-1432154316_thumb.pn

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
    post-2137-0-28278500-1432154545_thumb.pn
     
  • 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
    post-2137-0-34067100-1432154850_thumb.pn
    post-2137-0-03104800-1432154895_thumb.pn
     
  • 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:
    post-2137-0-34181300-1432155016_thumb.pn
    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 ;)

  • Like 12
Link to comment
Share on other sites

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?

 

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

  • Like 5
Link to comment
Share on other sites

 

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.

  • Like 1
Link to comment
Share on other sites

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:
post-2137-0-88064300-1432211868_thumb.pn
 
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

  • Like 9
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

post-2137-0-03961600-1432236064_thumb.pn

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D;)

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:

post-2137-0-45916400-1432280870_thumb.pnpost-2137-0-60997000-1432280869_thumb.pn

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

post-2137-0-63494800-1432284162_thumb.pn

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...