Fredi - friendly frontend editing

ryan · June 1, 2013

When I try to fill it with images using fredi on the frontend the edit modal pops up as expected and the "choose file" button for the field brings up my file explorer. When I choose an image you can see that the image is trying to load but nothing happens.

I'm not sure I totally understand the issue and might need a little screengrab/video to see exactly what you are talking about. But any javascript errors occurring in your JS console? It sounds like there would be two modals on top of each other here, and wondering if the targets are getting mixed up.

apeisa · June 1, 2013

Ryan, for some reason images / files inside repeater doesn't work in Fredi. I have (blindly) added setTrackChanges(true) in different places, but without any luck. I recorded screencast that should open this issue better:

(video works now).

I am pretty sure that the problem isn't JS side (console is silent, response seems to be ok). Problematic code is here (it works without repeaters just fine): https://github.com/apeisa/Fredi/blob/master/FrediProcess.module#L54

ryan · June 4, 2013

Thanks for the screencast Antti. Your cat sounds exactly like mine. This definitely helps clarify for me what the issue is. On the other hand, I'm still at a loss to know what is causing it. It's interesting to see the responses all appear successful and no indication of errors. I hope to experiment more with this soon. Correct me if I'm wrong, but doesn't it seem like the bit of code starting here is where it's getting stuck?

apeisa · June 4, 2013

Your cat sounds exactly like mine. This definitely helps clarify for me what the issue is.

You understand their language? My cat understand code? Joking aside, we actually have four cats and I have no clue which one is performing there...

I debugged this little more. The responses are actually totally wrong: it responses with page save instead of field save. This is what I get when saving in normal admin:

[
    {
        "error": false,
        "message": "Added file: desert.jpg",
        "file": "/frontendedit/site/assets/files/1037/desert.jpg",
        "size": 845941,
        "markup": "\n\t<li class='InputfieldFile InputfieldImage ui-widget'>\n\t\t<p class='InputfieldFileInfo ui-widget ui-widget-header'>\n\t\t\t<span class='ui-icon ui-icon-arrowthick-2-n-s'></span>\n\t\t\t<span class='InputfieldFileName'>desert.jpg</span> \n\t\t\t<span class='InputfieldFileStats'>• 826 kB • 1024x768</span> \n\t\t\t<label class='InputfieldFileDelete'><input type='checkbox' name='delete_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' value='1' /><span class='ui-icon ui-icon-trash'>Delete</span></label>\n\t\t\t<a class='InputfieldFileMove InputfieldFileMoveBottom' href='#'><span class='ui-icon ui-icon-arrowthickstop-1-s'></span></a> \n\t\t\t<a class='InputfieldFileMove InputfieldFileMoveTop' href='#'><span class='ui-icon ui-icon-arrowthickstop-1-n'></span></a> \n\t\t</p>\n\t\t<p class='InputfieldFileData ui-widget ui-widget-content'>\n\t\t\t<a class='InputfieldFileLink' target='_blank' href='/frontendedit/site/assets/files/1037/desert.jpg'><img src='/frontendedit/site/assets/files/1037/desert.0x100.jpg' alt='desert.jpg' /></a>\n\t\t\t<label class='InputfieldFileTags'><span class='detail'>Tags</span><input type='text' name='tags_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' id='tags_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' value='' /></label><label class='InputfieldFileDescription'><span class='detail'>Description</span><input type='text' name='description_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' id='description_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' value='' /></label>\n\t\t\t<input class='InputfieldFileSort' type='text' name='sort_images_2057dd75f2e9f7b52e3dda4ccd0ea4a2' value='1' />\n\t\t</p>\n\t</li>",
        "replace": false
    }
]

And this is what I get from ProcessFredi:

{
    "error": false,
    "message": "Saved page '1035' multiple fields"
}

So it seems that my code is too eager or something. This is where I believe the problems are: https://github.com/apeisa/Fredi/blob/master/FrediProcess.module#L54

ryan · June 6, 2013

You understand their language? My cat understand code? Joking aside, we actually have four cats and I have no clue which one is performing there...

We have 3 cats, and two of them are into singing. Your cat sounds like our cat Sasha.

I debugged this little more. The responses are actually totally wrong: it responses with page save instead of field save. This is what I get when saving in normal admin:

I'm thinking the gateway if() might be here. That $numFields variable must be greater than 1 since your JSON response says "multiple fields". Yet I think you want it to be 1. And it looks that could happen if HTTP_X_FIELDNAME wasn't set for one reason or another, here.

I don't understand the technical details of how Fredi works yet (though hoping to learn soon), but I do wonder if this could be solved by just sending the ajax post request to ProcessPageEdit only, rather than Fredi? The reason is that it seems like if something is hooking into ProcessPageEdit, that Fredi doesn't call, wouldn't get executed. An example is this line in FieldtypeRepeater, which I think is attaching a hook that doesn't get executed via Fredi.

One other thing, unrelated, is that it looks like these lines should be moved above the ajax section in your execute() function?

// Check if there is not such a page found
if ( ! $this->pageContext->id) throw new WireException("Page not found");

// Check that this page is editable by current user
if ( ! $this->pageContext->editable()) throw new WireException("You don't have right to edit this page")

apeisa · June 8, 2013

Yes, that's it. If I change fredi form to use /page/edit/ directly, the image field inside repeater works. But normal saving fails, and I think because the forms are different, so the processing doesn't go right. I tried to get them to same structure by getting page edit form and then removing the fields that aren't needed. But cannot get the removing going.

I have changed the renderFieldsForm to this:

public function renderFieldsForm() {
	$this->fieldsArray = explode("|", $this->fields);
		
	foreach($this->fieldsArray as $fieldName) {
		// Check if page has the field that wants to be edited
		if ( ! $this->pageContext->fields->has($fieldName)) throw new WireException("There is no field $fieldName on editable page");
			
		// Check if the current user has rights to edit that field
		if ( ! $this->pageContext->editable($fieldName)) throw new WireException("You don't have rights to edit field $fieldName");
	}

	$form = $this->modules->get('InputfieldForm');
	$form = $this->pageEdit->buildForm($form);
	$form->attr("action", "/processwire/page/edit/?id=$this->pageId&modal=1"); //TODO: url is hardcoded now..
	
	// Build the form (loop fields and add their respected inputfields)
	foreach($form->fields as &$field) {
		if ( ! in_array($field->name, $this->fieldsArray)) {
			$form->remove($field); // Script goes here, but it doesn't remove the field
		}
	}
	
	return $form->render();
}

I don't understand why, but $form->remove($field) isn't working.

Marty Walker · July 24, 2013

Hi Antti,

So I have Fredi installed, the header and JS code in place. My template edit access is set to admin as well as another role. I have a user setup with that role enabled. Can I still use Fredi for that non-superuser user?

Regards

Marty

DaveP · July 24, 2013

Marty, I'm sure Antti will confirm, but the basic tenet is that if the user has the correct permission(s) to edit in the backend then they can edit in the frontend with Fredi. I use Fredi on one site with several user types and all permissions apply across backend and Fredi.

Marty Walker · July 24, 2013

Thanks Dave. I thought as much. It might just be me being daft somewhere along the line.

NooseLadder · August 8, 2013

Hi,

I have just installed Fredi and am getting the following error when the edit window is displayed:

Notice: Undefined variable: out in \site\modules\Fredi\FrediProcess.module on line 116

$submit = $this->modules->get('InputfieldSubmit');        $form->add($submit);
        
        // If form was submitted, process it
        if (count($_POST)) return $this->processInput($form);
        
        $out .= $form->render();  // Line 112
        
        
        return $out;

arjen · August 8, 2013

It's just a notice. To fix this right now you can change it easily:

$out = $form->render();

Apeisa will propably fix this in his repo.

NooseLadder · August 8, 2013

It's just a notice. To fix this right now you can change it easily:
$out = $form->render();
Apeisa will propably fix this in his repo.

Thanks

muzzer · August 19, 2013

Hey Apeisa, just took this for a test run and she rocks! I have developed something very similar, but I have to say your effort is just quite a bit nicer. I'll have to pull it apart to see how do did it, and learn some stuff at the same time no doubt.

Awesome job, frontend editing is what I loved from modX, PW just gets better and it feels complete now

I see you were looking at adding a $fredi->newPage method, is this still on the cards? This would be the ultimate. Thanks for the awesome module

Edit: Hey, just noticed mention of work-in-progress on $fredi->newPage in another thread, look forward to seeing that.

muzzer · August 24, 2013

Don't know if anyone else is seeing this or it's something confined to my site, but when I use Fredi with a TinyMCE field and click the insert image icon I get an error:

TemplateFile: No page specified

It works fine in the backend.

Marty Walker · October 5, 2013

Hey Antti,

Does the current version support the "=50" field percentages that you mentioned? I'm using Fredi on the 2.3.5. PW build and I lose the 'edit' link whenever I try to use them.

apeisa · October 5, 2013

Marty, that is implemented here, but not yet committed. I will add that soon, since there seems to be lots of interest for Fredi lately.

apeisa · October 5, 2013

Ok, got little bit too excited and started building Fredi with Ajax saving & ajax page refresh (instead of the old clumsy submit => post processing => page reload). This is working great already, simplified code a lot and actually fixed the "images don't save inside repeaters" problem too.

I also changed the code so that you won't be able to define the columns, but those will be inherited from the actual template context. This is great now that Ryan made tweaks along field dependencies so that there won't be "empty" spots at all (if fields doesn't make 100%, then last one in row will get larger). I also believe that even field dependencies will work on Fredi now (not tested yet).

Only problem I am having currently: it seems AjaxSave method doesn't support multilang fields yet? https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L1037

I have only two languages: "default" and "test". If I change the default title value and save, that new value will be put on the test title and default will remain old.

apeisa · October 5, 2013

Note about ajax save & multilang: it actually save the default language to the langue that user has active. It ignores the others.

apeisa · October 5, 2013

Just pushed this "ajaxified" stuff on dev-branch: https://github.com/apeisa/Fredi/tree/dev

Hope you guys find time to test it. It feels superfast to use. Probably few bugs here and there, but we will sort those

Marty: I decided to leave the FieldName=<Width> syntax all together and it now uses whatever there is for the field on settings (old default was always 100% for each field).

apeisa · October 5, 2013

Hmm.. it seems repeaters don't work either (images inside repeaters do work, but images/files go different route). I guess that is because of lacking support in ProcessPageEdit::AjaxSave method, but not 100% sure about that.

Marty Walker · October 5, 2013

It does feel faster. Thanks for the update. The only thing I can see that doesn't work is image field re-ordering.

apeisa · October 6, 2013

Thanks Marty. That is probably also something that AjaxSave method in core doesn't support, at least yet.

I just pushed new version: I added animation after submit (modal goes small again with spinning wheel), which makes this feel faster than before. Also made some tweaks etc, and this version works great on IE (10 at least, not tested others yet, I don't believe this works in 8, but probably works in 9), Firefox and Chrome.

Hopefully someone of you Mac people can test if it works in Safari too?

Marty Walker · October 6, 2013

I'm using OS X Chrome 29.0.1547.65. After that update the modal window doesn't close on Submit

apeisa · October 6, 2013

have you made hard refresh? works great here with chrome. also tested with Android browsers i have and all works.

Marty Walker · October 7, 2013

Yeah I did a hard refresh, clear cache, cleared any other modules out and still no go with being able to get past Submit on the modal box.

In Safari (6.0.5) I just get a blank modal box.

Sign In

Fredi - friendly frontend editing

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Recently Browsing 0 members

Similar Content