Fredi - friendly frontend editing

[apeisa]

Thanks Marty! That is strange. Just tested it with Mac (through excellent browserstack). It doesn't work with Chrome 29 (and not in 30beta), but it does work on 31dev (also in mac).

Also tested with Safari 5.1, which has other issue (doesn't show the editing iFrame at all).

Since this works in IE and FF, so it must have been some bug in earlier chrome versions. I'll take a look at next weekend at latest. I would love to see this working in Safari too.

[renobird]

Hey Antti,

I'm experiencing the same issue as Marty (safari 6.0.5) — modal just shows the loading animation.

[apeisa]

yep, safari has actually different issue. it doesn't show edit page at all. stable chrome allows saving, but doesn't close modal. I am able to reproduce both issues, so should be able to fix after I find time.

[apeisa]

Ok, I think I nailed both of those bugs. In my tests this new ajaxified Fredi (available from dev branch) works great on FF, Chrome and Safari. Should work on IE10 too, but will test other IE:s later.

[renobird]

Antti,

Will grab and test now — thanks!

[renobird]

Working nicely here on:

Mac:

- Safari

- Chrome

- FF

Windows:

- IE9

- Chrome

After using this a good bit the last week, I think it might be a good idea to set 

body {overflow:hidden} 

via JS while the modal is open. That way only the modal will scroll.

I have some lengthy body fields and sometimes the multiple scrolling can get weird.

[renobird]

Spoke too soon.

Just tested on a page with additional JS. 

I can open and edit, but when the modal closes there is a silent JS issue that kills all the other JS on the page.

I'm not getting any errors or warnings.

Update: Modal never closes after save on IE9, just hangs.

[apeisa]

the way modal closes is bit experimental. it does Ajax request to its own URL and then replaces body content. so all elements will be fresh ones. that us probably problem with js freeze. can you provide an URL for me to test that js case?

thanks for testing tom!

[Marty Walker]

I can submit now but I still can't get images to reorder.

http://smdstuff.s3.amazonaws.com/fredi-PW253.mov

[apeisa]

Oh, sorry Marty. Didn't take a look at that one yet. It is somethig that needs to be supported by AjaxSave method in PW core.

And thanks for testing!

[renobird]

the way modal closes is bit experimental. it does Ajax request to its own URL and then replaces body content. so all elements will be fresh ones. that us probably problem with js freeze. can you provide an URL for me to test that js case?

Unfortunately I don't have a way to open this site up yet. It's restricted using Shibboleth for authentication, so there's no way to create an account for a non-university user.

[apeisa]

How about now guys? In my tests this works great now on FF, Chrome (older ones too), Safari and IE9+.

Tom: I believe that your JS-issue is also fixed by this update. Also implemented the overflow: hidden, thanks for that - it works great.

Marty: Should work, but those image positions and repeater stuff still missing from AjaxSave method in PW core. I will start looking for that next (probably something that is relatively easy to support, but not sure yet and needs to be committed into core too).

[renobird]

Antti,

I've just done some basics, but it seems to be working great now! 

Mac:

- Safari

- Chrome

- FF

Windows:

- IE9

- Chrome

I hope the sorting issue isn't too difficult to conquer — that's that last piece I would need to make this production ready.

Thanks for all your hard work.

[Soma]

I'm using latest dev of this module and it doesn't work with multilanguage. When editing alternative language it doesn't save it. It's still same as before editing.

Also there's a warning when using renderAll() viewing an alternative language:

Notice: Trying to get property of non-object in /home/updatepu/www/reitsimulator.ch/wire/core/Page.php on line 1239

Which results in the link not working cause httpUrl doesn't work correct.

Trying switching back to master.

Edit: with master it does save the alternative language fields again, but the warning above and broken link persists. I'm using latest PW.

[Soma]

Edit: Ok as with some other modules (FormBuilder) too when using multilanguage the process page or any page that the module installs isn't active in the alternative language (LanguageSupportPageNames), so after enabling "english" on the FieldEdit Fredi process page the warning is gone. Tricky.

[apeisa]

But the saving problem persist? I guess that is also because ajax-saving in PW-core doesn't support multilang yet.

[Soma]

Ah that must be it. Yeah the problem persists.

[Marty Walker]

Hi Antti,

Do you know if the core got the updates you needed for repeater reordering?

Edit: Looks like it didn't. I still can't (but would really love to) use Fredi and reorder a repeater.

[apeisa]

Oh, it seems my latest reply from few months went to Marty's message (it seems I pushed edit instead of reply)... so here it is:

How about now guys? In my tests this works great now on FF, Chrome (older ones too), Safari and IE9+.

Tom: I believe that your JS-issue is also fixed by this update. Also implemented the overflow: hidden, thanks for that - it works great.

Marty: Should work, but those image positions and repeater stuff still missing from AjaxSave method in PW core. I will start looking for that next (probably something that is relatively easy to support, but not sure yet and needs to be committed into core too).

[quickjeff]

@apeisa 

Awesome! Awesome! Awesome! Module, you have allowed me to almost complete my project. 

I have run into an issue. 

I have a field that requires a check mark to display the appropriate fields.  

I wrote this script and am trying to allow editing to certain fields but only half of them show.  I double checked the field names and still no go. Only half work. 

Below is what I have:

 <?php
if($page->type_bar_club){

 echo $fredi->render("clublogo|featured_city|flyer|flyer2|second_promo_details");
 
 }
 
 ?> 

In the head.inc I have this script:

  
   <?php //loading front end editor
   
	 $fredi = $modules->get("Fredi");
	 echo $fredi->renderScript();
	?> 

Im not sure what the issue is. 

[quickjeff]

Nevermind, I figured it out.  It was the show if dependency that was throwing it off.  My mistake!!! Thanks again for the awesome module!

[Pete]

I had to stop liking your posts Antti because I was wearing my mouse out

I should have been using this to save time on a tonne of stuff recently, but I hadn't noticed that you could create new pages with it now. It will be a huge timesaver for a bunch of simple pages that have tabular data as I can now add new "rows" (new page) and edit current rows (edit page) using Fredi without having to roll my own templates and code to reinvent the wheel

[JasonS]

Is it only view-able on front-end for admin, I realized it doesn't show links for my other roles. Is this expected?

[apeisa]

Yep, user should have page edit access to content they are editing.

[JasonS]

I can't figure out how to have it displayed for a custom role I created ("member").

I even allowed the template to control who has access and edit permissions to this page. Seems not to be working...

I've ran out of idea.

I have a template("Profile") which has fields from the built-in "user" template. The Fredi links works as expected for the "superuser" role, but doesn't show for the custom role "member".

Do you have any suggestions or am I missing something here? 

Thanks in advance for any help you can give me.