Jump to content

Fredi - friendly frontend editing


apeisa

Recommended Posts

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...

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

Link to comment
Share on other sites

  • 4 weeks later...

@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.  >:(

Link to comment
Share on other sites

  • 1 month later...

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

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

Link to comment
Share on other sites

  • 4 months later...

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.

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
×
×
  • Create New...