Fredi - friendly frontend editing

[apeisa]

Fields get the styling from your admin theme - so implementing custom admin theme you get custom look in editor view.

And yes, you can style the modal to your liking. Just overwrite the default styles or don't load them at all.

[3fingers]

Super quick response, thanks! 

[apeisa]

I think I could add custom.css that allows modifying fredi fields without touching to admin theme. That would be helpful here.

[3fingers]

That would be a killer feature IMHO, because I'm not really sure I want the same style I've got for the front-end for the whole back-end section.

Css per modal window would be great to give the user a seamless Ux throughout the navigation.

If you could add that I'll definitely make myself naked on cam for you....(of course...not ).

[alxndre]

Great module, antti! I've been playing around with it and it looks great! 

Is there a way to use the column width of the inputfields as defined in the templates? It would be nice to preserve the layout of the fields and show it like how it is on the backend.

Edit: evan's screenshots looks like it has column widths, but how?

Thanks!

[3fingers]

I didn't play with Fredi just yet but you could try to change the width of the modalbox (via css or with Chrome Developer Tools / Firebug) to fit to the width of the main container of your admin-theme, to check if the fields floats.

Probably is not enough, but you could give it a try

[alxndre]

I tried your suggestion, nothing changed. All fields are stacked at 100% width.

[apeisa]

I started to implement the custom css, but I soon realized it is already supported. Since FrediProcess is process module, it will automatically load FrediProcess.js and FrediProcess.css files if available. So those fields will be loaded inside iframe if you just create them. I added this to tips and tricks section of documentation.

About field widths: currently it "supports" the widths that are given directly to the field (not in template context). I could change it to support template context too. But I probably take totally different route here. Let me explain: you don't always have all the same fields in modal than you have in admin. Order might be different.. so when we take those widths from admin context and use them in fredi modal, we might get very messy looking forms.

One possibility (and the one I most probably will eventually go for) is to have options for Fredi, so you could give more settings on the fly. Things like field visibility, width etc.

One thing I will add for sure is to overwrite the default "edit" text, so you could go with edit links like: "edit body text", or "edit images from homepage", "customize footer" etc.

[alxndre]

 

One possibility (and the one I most probably will eventually go for) is to have options for Fredi, so you could give more settings on the fly. Things like field visibility, width etc.

 

This sounds great, and even better than getting the width from the context. I have been looking into the code, and if I understand it correctly, I might be able to help with this.

[apeisa]

Added support for custom text in edit links. Usage is like this:

$fredi->setText("Edit bodytext")->body;
// or
$fredi->setText("Edit headline and title")->render("headline|title");

Also all the fields are 100% width now, not sure yet about best way to go with custom widths/settings for fields. All ideas welcome Alxndre'

[3fingers]

...Since FrediProcess is process module, it will automatically load FrediProcess.js and FrediProcess.css files if available. So those fields will be loaded inside iframe if you just create them...

Sounds really good, I'll give it a try as soon as possible.

Congrats apeisa, this module, thanks to your continuous integrations and adjustments, is going to be a "must have" for my projects.

[adrian]

Hey Antti,

I love the flexibility of editing options for this module and since you are doing such an awesome job, can I add some additional 'ultimate goal' options without seeming greedy and unappreciative?

• I have a structure where I am drawing content from one page structure of people and populating it on several different pages on the front-end based on tags within the main structure (more details here: http://processwire.com/talk/topic/3279-getting-fake-urls-with-urlsegments-returned-in-search-results/). I set up Fredi to use the $another_page option, which is perfect for editing these page fields on the front end. The problem is that when I submit, it redirects to the page that doesn't exist on the front-end. Could Fredi be made smart enough to redirect back to the page it was on when editing was initiated instead?
   
• Because of the same issues above, front-end creation of a new child page is difficult. Your excellent AdminBar (which works great on the other sites I am using it with), fails when trying to create child pages in this scenario. Could Fredi handle this with the $another_page option?
   
• Maybe it's just me, but I actually liked the quasi tab-like approach of AdminBar, compared with the Fredi modal. That said, do you have any plans to integrate the inline editing of CKEditor into Fredi and make editing seamless?
   
• Any chance of an option for all fields, rather than needing to write them all out like echo $fredi->render("headline|title|summary"). As an example, these people pages in my example above have 13 fields. Seems like: $fredi->render("allfields") or something like that would be a nice enhancement.

Please let me know if I can provide a better explanation of any of these.

Thanks!

[Soma]

I use modal frontend editing in PW since the beginning.

It's as easy as providing a edit link that open in a iframe modal and add ?modal=1 to the url..

I wrote and showed even code example in this thread. http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/

Just seems nobody really bothered about it, but go all crazy with this module.

[adrian]

Hi Soma,

I actually played around with your iframe modal approach for my first PW site a couple of months ago. It gave me lots of idea, so thank you

In the end I decided against it - I feel like modal works well for single fields, but not all the fields of a complex pages - seems crowded and messy when you have to scroll in a modal. I actually built a very basic edit mode - actually kind of like AdminBar (but nowhere near as slick) - I hadn't discovered AdminBar at the time. It had the ability to add edit buttons for each repeated section (child page) of content, without needing to be on the specific child page.

I think there are so many cool ways to go with this and I am excited to see how this evolves.

[apeisa]

Thanks everyone about the support. I have implemented this on few of our demo/test sites (takes about 2 min per template) and it was total breeze and the speed and simplicity of editing is amazing. Even better than I thought.

Hey Antti,

I love the flexibility of editing options for this module and since you are doing such an awesome job, can I add some additional 'ultimate goal' options without seeming greedy and unappreciative?

Thanks for the great words. And yes, all ideas are welcome

I have a structure where I am drawing content from one page structure of people and populating it on several different pages on the front-end based on tags within the main structure (more details here: http://processwire.com/talk/topic/3279-getting-fake-urls-with-urlsegments-returned-in-search-results/). I set up Fredi to use the $another_page option, which is perfect for editing these page fields on the front end. The problem is that when I submit, it redirects to the page that doesn't exist on the front-end. Could Fredi be made smart enough to redirect back to the page it was on when editing was initiated instead?

You don't happen to have adminbar installed also? I have noticed that behaviour when I have adminbar installed (it does that redirect). Without adminbar it should stay on same page.

Because of the same issues above, front-end creation of a new child page is difficult. Your excellent AdminBar (which works great on the other sites I am using it with), fails when trying to create child pages in this scenario. Could Fredi handle this with the $another_page option?

I have been thinking wheter I allow creating new pages with Fredi or not. It shouldn't be that hard though. Syntax might be something like $fredi->renderNew("template", $parent_page); I might give this one a go.

Maybe it's just me, but I actually liked the quasi tab-like approach of AdminBar, compared with the Fredi modal. That said, do you have any plans to integrate the inline editing of CKEditor into Fredi and make editing seamless?

I am not sure I understand the relation from AdminBar to CKEditor. Biggest "idea" of Fredi is that because it fields on modal (using iFrame), we get all the candies from admin for "free". Meaning ajax uploads, datepickers, repeaters... you name it. With adminbar you get same goodies, but you always edit whole page. So you cannot click close the relevant content and you have to "find" the correct field from admin view.

Adding special treatment for ckeditor fields doesn't fit for Fredi I think. That is the direction I have been thinking about long time, and it always meant lot's of work and end resolution would always be "halfway there" - meaning support only for textfields (or even more work to make any other fields working). For the same reason Fredi does "full reload" after each edit. It is close to impossible to have ajax refresh, since Fredi cannot know all the places where content is used.
 

Any chance of an option for all fields, rather than needing to write them all out like echo $fredi->render("headline|title|summary"). As an example, these people pages in my example above have 13 fields. Seems like: $fredi->render("allfields") or something like that would be a nice enhancement.

That is a good idea. Though syntax will be $fredi->renderAll($another_page);

[adrian]

Uninstalling AdminBar fixed the redirect issue - thanks, and sorry if I missed that mentioned somewhere else. It would be great to have that simplified version of AdminBar you mentioned too, to work with Fredi.

I think the new page option is an important addition - thanks for looking into it.

Sorry if my AdminBar and CKEditor inline editing link was confusing. I am not completely convinced about inline editing - I just know there has been a fair bit of discussion about it in this forum. I thought the ability of Fredi to limit editing to specific fields could be tied into inline editing with some visual cue to identify which fields are editable. Anyway, sounds like that is for a future module.

renderAll() looks much better  

[AnotherAndrew]

apeisa, you are my hero! A client was looking for this option just today. I will try it out and thanks for all your hard work!

[alxndre]

That is a good idea. Though syntax will be $fredi->renderAll($another_page);

Perhaps the template context would be useful here now to render the widths of the field.

[apeisa]

Yep, definitely in that case, when all fields get rendered.

[apeisa]

Any chance of an option for all fields, rather than needing to write them all out like echo $fredi->render("headline|title|summary"). As an example, these people pages in my example above have 13 fields. Seems like: $fredi->render("allfields") or something like that would be a nice enhancement.

I wrote and showed even code example in this thread. http://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/

Just seems nobody really bothered about it, but go all crazy with this module.

Since these comments might give impression that Fredi is just page editing in a modal (like AdminBar does) I just wanted to mention that the main difference (and the only reason I wrote this module), is you can use Fredi per field basis. That means you can build super nice front end editing UI, where you have edit icons just next to the content you want to edit. When you have over 10 fields per page it might be confusing for users trying to figure out where content is shown. Seeing clients used AdminBar never made me happy - with big templates they were just lost and it would have been nicer to just send them to actual admin page. 

That being said - modules like Fredi really makes the line between content and visuals more unclear and are not a great fit for all sites.

And while "field at the time" was the main driver, I can see the benefit for having full page edit modals also (although if template has 13 fields, I would cut that to three or five edit links, based on how the layout works in frontend).

$fredi->renderAll() is now implemented - currently it also allows deleting and creating child pages (not sure if I like that).

[adrian]

Hi Antti,

Sorry if those comments seemed unappreciative. I completely see the value of being able to edit single fields separately on a page. Perhaps the idea of RenderAll doesn't really fit well with this module. Personally, the biggest benefit for me with Fredi is the ability to edit content from other pages - this is where AdminBar lets me down.

I guess I am thinking of a way to combine the best of both somehow. I'll let you know if I have any brilliant ideas

[apeisa]

Adrian, nothing like that. I have been super happy with all the great feedback and ideas you have gave. Keep em coming!

I played with renderAll little more and not entirely sure if it really fits... Gotta get some real life experiences before deciding.

[AnotherAndrew]

Apeisa, I have tried to installing this module but I am getting: 

Notice: Undefined variable: fredi in ......./header.inc on line 31

 

Fatal error: Call to a member function renderScript() on a non-object in ....../header.inc on line 31

 

I have this before the close of the head tag:     <?php echo $fredi->renderScript(); ?>

 

I can't seem to figure out what I am doing wrong. Thoughts?

[diogo]

Did you load fredi before? $fredi = $modules->get("Fredi");

[AnotherAndrew]

Ahh no. I was calling it afterwards. Thanks diogo!