Jump to content
apeisa

Fredi - friendly frontend editing

Recommended Posts

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
 
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. :)

Share this post


Link to post
Share on other sites

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' :)

Share this post


Link to post
Share on other sites

...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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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. :D

  • Like 4

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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. :D

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).

  • Like 2

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By MoritzLost
      This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions.
      The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu:
      Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides:
      An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README.
      Beta release
      Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site.
      Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement!
      In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me.
      Future plans
      If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind:
      Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions!
      Links
      https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory

    • By joshua
      This module is (yet another) way for implementing a cookie management solution.
      Of course there are several other possibilities:
      - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/
      - https://github.com/webmanufaktur/CookieManagementBanner
      - https://github.com/johannesdachsel/cookiemonster
      - https://www.oiljs.org/
      - ... and so on ...
      In this module you can configure which kind of cookie categories you want to manage:

      You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience.
      Currently there are four possible cookie groups:
      - Necessary (always enabled)
      - Statistics
      - Marketing
      - External Media
      All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ...
      When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax:
      <script type="optin" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="optin" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="optin" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The type has to be "optin" to get recognized by PrivacyWire, the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision.
      If you want to give the users the possibility to change their consent, you can use the following Textformatter:
      [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie.
      You can also add a custom link to output the banner again with a link / button with following class:
      <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> This module is still in development, but we already use it on several production websites.
      You find it here: https://github.com/blaueQuelle/privacywire/tree/master
      Download: https://github.com/blaueQuelle/privacywire/archive/master.zip
      I would love to hear your feedback 🙂
      Edit: Updated URLs to master tree of git repo
       
    • By David Karich
      Admin Page Tree Multiple Sorting
      ClassName: ProcessPageListMultipleSorting
      Extend the ordinary sort of children of a template in the admin page tree with multiple properties. For each template, you can define your own rule. Write each template (template-name) in a row, followed by a colon and then the additional field names for sorting.
      Example: All children of the template "blog" to be sorted in descending order according to the date of creation, then descending by modification date, and then by title. Type:
      blog: -created, -modified, title  Installation
      Copy the files for this module to /site/modules/ProcessPageListMultipleSorting/ In admin: Modules > Check for new modules. Install Module "Admin Page Tree Multible Sorting". Alternative in ProcessWire 2.4+
      Login to ProcessWire backend and go to Modules Click tab "New" and enter Module Class Name: "ProcessPageListMultipleSorting" Click "Download and Install"   Compatibility   I have currently tested the module only under PW 2.6+, but think that it works on older versions too. Maybe someone can give a feedback.     Download   PW-Repo: http://modules.processwire.com/modules/process-page-list-multiple-sorting/ GitHub: https://github.com/FlipZoomMedia/Processwire-ProcessPageListMultipleSorting     I hope someone can use the module. Have fun and best regards, David
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "https://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


×
×
  • Create New...