apeisa

At the moment cropping is just for template usage, not for rte. Dimension thing is probably doable, but I haven't had the need for it yet.

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. Thanks for the great words. And yes, all ideas are welcome 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. 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. 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. That is a good idea. Though syntax will be $fredi->renderAll($another_page);

Nothing ready. Other way around there would be api module (servicePages if I remember correctly). It is just the same as any other form. Just define the required stuff, url where to post and possible hash and you are ready to go. Also tell what you are going to return if success or not.

This module reminded me of Select2 - it's like asmSelect supercharged: textboxes like this, filters, custom labels, ajax etc That being said, it would be great to have Select2 as a Page field inputfield in PW.

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'

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.

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

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.

It is little outdated (just visuals, code is right), so I removed it. But I added it back to first post until I record new one. Just noticed that there is nice typing sounds included

If you check the ip, then that is pretty good authentication. But since you are creating users, sending email etc you cannot be too careful. Good and simple solution is to calculate simple hash from posted params and add shared secret in too. So only you and the third party know how to calculate the hash. Before doing anything on your side you calculate the hash and if it matches (third party sends hash as a post param too) you continue and return success message. Hash can be something like md5($username . "abc123" . $email).

That is good news (hopefully will be soon fixed on android chrome too).

Do you have debug on?

Just looked the code from mobile: you should check that $page has admin template. Now it adds js code to public pages also.

Looks great and congratulations on your first child nikola! Can't wait to test this.

That is one way to go - or at least see how to modify the paths. Although I would much more prefer having /nl/ on the urls (I don't see anything bad in that). Modifying the path can get messy.

Marty, that is strange. Works fine here (chrome 26), although I have same problem with Android Chrome. Mind testing again when you have updated to 26? Evan, good idea!

I just added this to module directory, pushed documentation to github and consider this pretty much released.

I like this idea. Overriding family settings is one that I would like to see. Often while developing you have to move/create pages in places where they aren't really allowed by family settings.

I implemented custom modal for this. Seems to work great on IE10, Chrome, FF, iPad, iPhone... but having little issue with chrome on android.

That is true. I think it should be on advanced tab - it is something that can be very valuable on site building, not just for core/module development (which is where advanced mode is used).

That would help with cropping too

I am currently building own responsive js modal (without any library dependencies), so soon we can have bigger edit view.

Thanks guys. Wanze: when I got the idea of how this should work I had kind of light bulb moment. I have been thinking about front end editing in PW about two years and I think now I have nailed the right ingredients AdminBar feels like a hack now. Although I am planning simplified AdminBar which would integrate with this. It doesn't need to do anything else than provide fredi switch and full edit link.

Must be on dev, since I am on latest master.

Yeah, it seems to work for me with language page names. But I don't see that active checkbox? Where does it comes from?