[SOLVED] Fabrik + Sh404 - Fabrik upload element (ajax version) "page reloads" on delete

[wolter]

This happens with the file upload element (Ajax Version) only.

Pressing on the X (delete) to delete the uploaded file, causes the page to reload, when sh404 is enabled.

I have talked to the sh404 developer, he told me that it might be (Fabrik) that causes the page reload, since sh404 SEF extension perfectly follows Joomla API. Any ideas what can be the cause to this behaviour ?

Cheers

 

[lousyfool]

I'm using both AJAX file upload and sh404SEF on a site, and I'm not aware of such issue. But then this may be due to my specific sh404SEF setup or else...
Unfortunately, I can't perform tests since it's a client's live site (and it's huge, incl multi-site extension and more, all of which doesn't allow simple cloning for testing purposes).

When inspecting the X, what do you see? <a href="#"> as intended, or else? Any JS errors before click, or any other strange behaviour before/after?

 

[wolter]

I received an Answer from the sh404 dev which might help:

He mentioned that it should be noted that (fabrik) do make the ajax request, it's happening normally in all cases. However, they (fabrik) do not prevent the click on the <a> element and that's what's causing a page reload. The reason for that is in their (fabriks) javascript somewhere, see image. Hope this can be to any help.

 

[wolter]

I have a test server where you can test it out, dont know if it is ok to post login details here ?

 

[lousyfool]

I have a test server where you can test it out, dont know if it is ok to post login details here ?

This is a public forum, so I'm not sure if it's a good idea to post them here.

[Edit:] Obviously PMs are working.

 

[wolter]

This is a public forum, so I'm not sure if it's a good idea to post them here.
PM me, and if that doesn't work.

Great, i sent you a PM.

Thanks, really appreciated!

 

[lousyfool]

For the record:

1. The problem occurs only when an existing record is being edited, not when a new record is being added. Actually, it's working fine with new records.

2. When editing a record and clicking the X to delete an AJAX-uploaded file in the form, it's not the form page which is being reloaded (as put by the OP). Instead it's the site's homepage where one is landing, because the URL for the X is wrongly http://domain.com/index.php# (even with J! SEF on and suffix off).

3. It's not depending on J! template, it's the same in Protostar.

4. When disabling the fileupload element, the JS error related to "classList" still remains while all others are gone. Haven't been digging further, so this "classList" JS error may well be caused not by the fileupload element but by something else.

Anyhow, even though trying different settings in both Fabrik and sh404SEF, the issue persists. For now I'd recommend sticking in sh404SEF with the Joomla router for Fabrik if the AJAX fileupload is to be used and the ability of file deletion in existing records matters. But someone else may have a better idea where the culprit is and how to fix it...

 

[lousyfool]

Important update:

A different ("dev") version of sh404SEF exists with which the problem does not occur.

Conclusion: whatever the culprit, it is on sh404SEF's side unless someone proves differently.

 

[wolter]

For the record:

1. The problem occurs only when an existing record is being edited, not when a new record is being added. Actually, it's working fine with new records.

2. When editing a record and clicking the X to delete an AJAX-uploaded file in the form, it's not the form page which is being reloaded (as put by the OP). Instead it's the site's homepage where one is landing, because the URL for the X is wrongly http://domain.com/index.php# (even with J! SEF on and suffix off).

3. It's not depending on J! template, it's the same in Protostar.

4. When disabling the fileupload element, the JS error related to "classList" still remains while all others are gone. Haven't been digging further, so this "classList" JS error may well be caused not by the fileupload element but by something else.

Anyhow, even though trying different settings in both Fabrik and sh404SEF, the issue persists. For now I'd recommend sticking in sh404SEF with the Joomla router for Fabrik if the AJAX fileupload is to be used and the ability of file deletion in existing records matters. But someone else may have a better idea where the culprit is and how to fix it...

I got this answer from the weeblr team regarding this post, hope it can help to get some insight regarding this issue :

The problem is not that the URL "called" is wrong. The problem is that no URL should be "called". This is supposed to be an ajax request. An ajax request does not reload the content of the browser. An ajax request makes a call to the site, which URL it calls has no relation to the URL displayed in the browser address bar and no relation either with the href attribute of the link (you don't need a link to make an ajax call).

So first, when deleting a file, the form is not used. The form is only used and submitted when you press the Save or Apply buttons at the bottom.

The Delete icon is just a "fake" link (it should really be a button) with an href of "#". That URL is not changed. By sh404SEF or anyone. The URL of that delete link is the same whether sh404SEF is in use or not. The actual URL of the link is:

That link, #, is the same at all time. It's a kind of link used by many programmers when they do not want the browser to follow the link but instead take over the link with some javascript.

Like I said above, the Fabrik Javascript does make the ajax request normally - you can see the request in the Network tab of your developers tools. What it fails to do is block the browser from following the link. This is where the bug lies.

I have looked again at the differences between when sh404SEF is enabled and not. The actual difference is that the form URL is different.

With sh404SEF:

/index.php?option=com_fabrik&Itemid=118&formid=1&lang=en&listid=1&rowid=22-cute-cats&view=form

Without sh404SEF:

/en/fabrik-list/form/1/22-cute-cats

So I'm pretty sure that's what causing the Fabrik javascript to hit a bug in their code and not block the browser from submitting the form.

I can't be sure but it's only the Fabrik developers that can look at their code and understand what having a different URL for the form page would cause them to actually submit the form. This is typical of extensions assuming that the URL is always going to be the Joomla SEF URL and what I was discussin above.

No user on the forum can actually look at what happens and have an informed opinion without looking at the Fabrik javascript code. I started doing that but it's compressed and cannot be easily followed in that form.

 

[wolter]

[Problem is solved,] thanks to Weeblr team looking into this. Hope the Fabrik team can adjust this in coming update.

The bug is in file /plugins/fabrik_element/fileupload/fileupload.js at line 676:

The code:

.on('click', function (e) {
e.stopPropagation();
self.pluploadRemoveFile(e);
})

should be:

.on('click', function (e) {
e.preventDefault();
e.stopPropagation();
self.pluploadRemoveFile(e);
})

The delete button behaves as expected after that. Note that the same error is found in multiple locations on the same file so all would need to be fixed to completely solve the problem. It may also occur in other js files, but not checked.

 

[wolter]

Short notice.

For those of you who want to apply this change ASAP, have in mind that fileupload.js is the source file BUT Fabrik loads fileupload-min.js so youll have to edit the fileupload-min.js which can be a little bit trickier since its compressed / minified, use an unminifier/minify tool and your all set, just be careful.

Change the following file /plugins/fabrik_element/fileupload/fileupload-min.js at around line 362: (unminified)


The Code

.on("click", function (e) {
e.stopPropagation(), t.pluploadRemoveFile(e);
})


Should be

.on("click", function (e) {
e.preventDefault(), e.stopPropagation(), t.pluploadRemoveFile(e);
})


Save, empty the browser cache, reload and it should work.

 

[lousyfool]

@wolter: Thanks, also to the sh404SEF guys, for figuring it out and sharing it here.

If you've tested the modification sufficiently and are sure it's working without other side effects, you should make it a pull request at https://github.com/Fabrik/fabrik -- that'd be the way to make sure it'll be in the code for everyone asap.

I'm still wondering why the sh404SEF devs didn't keep whatever they did in their code to make it work, no matter what. Not least because Fabrik isn't the only app using <a href="#"> for JS functions, and certainly not the biggest one with its relatively small user group, etc. But that might be a different discussion altogether.