[Workaround] CyberDuck 4.4 issue - templates getting deleted.

Chris D

XenForo developer
Staff member
This is basically a warning to any one who uses CyberDuck to connect to XenForo's webdav system for the purpose of editing templates.

The latest version, 4.4, introduces a pretty major issue for XenForo users: templates get deleted:

2013-10-25 16:55:44 Public template:

Please enter a title using only a-z, A-Z, 0-9, _ and . characters.

This is logged in the webdav-error.log file. The file I was working on was simply "webdav_test.html". I haven't yet done any more debugging.

The end result, sadly, is whatever template you are working on is completely deleted from XenForo.

I'm going to tag @Mike in case he can see anything which may delete a template via XenForo's WebDAV server under certain circumstances in case that behaviour can be adjusted.

Failing that I am putting it down to be entirely a CyberDuck issue and I will be raising a defect report at their site. I was reluctant to post this as a bug here on the basis that XenForo WebDav seems to work fine in other apps, and certainly seemed to work in Cyberduck 4.3.

In the mean time, do not upgrade Cyberduck and stick to your original version.

Personally, I'm now looking for another solution. Transmit on Mac seems pretty clunky and slow and I'd prefer a solution that also works on Windows. It seems the latest version of PHP Storm struggles to open templates from the older version now.

Fun fun!
 
Unfortunately the exact name it's sending through is a little hidden because the title wasn't set since it passed in some invalid characters.

I've seen some situations where these programs actually do something like save to ~filename.ext and then try to rename it to filename.ext. Since that first part fails, that may cause the problem. Look at settings related to saving backup copies.
 
The CyberDuck developer has provided a workaround.

In Mac terminal.app you can run this command:

Code:
defaults write ch.sudo.cyberduck editor.upload.temporary false

For Windows:

Quit Cyberduck if it is currently running before editing any configuration file. You need to add the setting to AppData\Cyberduck.exe_Url_*\[Version]\user.config as follows:

Code:
...
<setting name="CdSettings" serializeAs="Xml">
  <value>
    <settings>
      <setting name="editor.upload.temporary" value="false" />
      ...
    </settings>
  </value>
</setting>
...

You can of course just use 4.3.1... If it ain't broke...
 
@Mike

This is some further detail from Cyberduck people. They're still blaming it on a server bug, rather than their client. Which, although might be true, all I bloody want them to do is have a switch to toggle that feature off...

Code:
Status changed from reopened to closed
Resolution set to thirdparty
To summarize.

although we send a expectation request for the PUT with Expect: 100-continue header, the server replies with a 100 status code to continue instead of forbidding the upload because it does not meet its internal filename length requirement.
The MOVE command fails with a forbidden response but still the original file seems to get overridden as reported by the user. This is clearly another bug in the server implementation.
 
And this may be relevant.

This is their log of a template being updated successfully in version 4.3.1. This is before the file name change feature was implemented for files modified in external editors:

Code:
PROPFIND /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test14.html HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.3.1 (Mac OS X/10.9) (i386)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 207 Multi-Status
Date: Fri, 25 Oct 2013 19:44:47 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 504
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/xml; charset=utf-8
GET /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test14.html HTTP/1.1
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.3.1 (Mac OS X/10.9) (i386)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 200 Ok
Date: Fri, 25 Oct 2013 19:44:47 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
ETag: aab3238922bcc25a6f606eb525ffdc56
Content-Length: 2
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
PUT /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test14.html HTTP/1.1
Expect: 100-continue
Content-Length: 10
Content-Type: text/html
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.3.1 (Mac OS X/10.9) (i386)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 200 Ok
Date: Fri, 25 Oct 2013 19:44:56 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
X-Pad: avoid browser bug


This is the log with 4.4 which shows the error:

Code:
GET /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test13.html HTTP/1.1
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.4 (Mac OS X/10.9) (x86_64)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 200 Ok
Date: Fri, 25 Oct 2013 19:40:56 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
ETag: c51ce410c124a10e0db5e4b97fc2af39
Content-Length: 2
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
PROPFIND /admindav.php/Public_Templates/Master%20Style%20%280%29/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.4 (Mac OS X/10.9) (x86_64)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 207 Multi-Status
Date: Fri, 25 Oct 2013 19:41:05 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml; charset=utf-8
PROPFIND /admindav.php/Public_Templates/Master%20Style%20%280%29/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset=utf-8
Content-Length: 99
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.4 (Mac OS X/10.9) (x86_64)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 207 Multi-Status
Date: Fri, 25 Oct 2013 19:41:06 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml; charset=utf-8
PUT /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test13.html-b421701a-f176-4284-a052-dc431d76876c HTTP/1.1
Expect: 100-continue
Content-Length: 11
Content-Type: application/octet-stream
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.4 (Mac OS X/10.9) (x86_64)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
MOVE /admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test13.html-b421701a-f176-4284-a052-dc431d76876c HTTP/1.1
Destination: http://localhost/admindav.php/Public_Templates/Master%20Style%20%280%29/webdav_test13.html
Overwrite: T
Host: localhost
Connection: Keep-Alive
User-Agent: Cyberduck/4.4 (Mac OS X/10.9) (x86_64)
Authorization: Basic Q2hyaXMgRGVlbWluZzpCaWdmb290MTIz
HTTP/1.1 403 Forbidden
Date: Fri, 25 Oct 2013 19:41:07 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 471
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: application/xml; charset=utf-8
HTTP/1.1 204 No Content
Date: Fri, 25 Oct 2013 19:41:07 GMT
Server: Apache/2.2.23 (Unix) mod_ssl/2.2.23 OpenSSL/0.9.8y DAV/2 PHP/5.4.10
X-Powered-By: PHP/5.4.10
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
 
Just bumped in to this issue. What a buggy pile of junk (Sabre/WebDAV).

It would be great if we could shift XF templates to the filesystem for development work, then sync back for production. A couple of e-commerce platforms and content management systems do this quite effectively.

@Mike Are there any plans for better template editing? I think a 3rd party had an alpha version of templates on the file system working at some point. You might see more diverse and higher quality XF styles if this was an option.

Please don't suggest that I edit hundreds of templates in a <textarea> when I have a perfectly capable and much more powerful editor running locally ;)
 
Although not well suited to what we want to do with XenForo, Sabre and WebDAV itself isn't the problem.

One problem is making XenForo work within the confines of the WebDAV protocol which is where the Cyberduck issue lies. XenForo has certain constraints on template names that WebDAV doesn't, so if Cyberduck want to start changing file names (as they have done for version 4.4), they will do so as long as that is within the constraints of what is allowed by the WebDAV protocol.

In that case then actually the issue lies with XenForo. But it's not necessarily appropriate for XenForo to start allowing all sorts of weird and wonderful template names and combinations as ultimately they need to be stored in a database which has its own constraints on inputted values.

So what it does indeed underline is that WebDAV isn't the best suited solution for XenForo. Generally, though, WebDAV and Sabre works.

I spoke with Mike about this and I echoed your desire to be able to modify templates in the file system. It's by far preferable. We'll have a much greater level of control and functionality by using an external editor. The trick will be ensuring that the solution will work well for both add-on developers and style people.

For now, though, as who knows - it might be one of those changes that's so radical we might not see it this side of XenForo 2.0 - I recommend sticking with Cyberduck 4.3.x. That at least does still do the job nicely.
 
Thanks for your insightful comments, Chris.

I've had a rather poor track record with XF/WebDAV, so there's a bit of resentment. :) Regardless, it certainly seems like the wrong tool for the job, or perhaps a rushed solution that we're still stuck with.

I appear to have WebDAV working somewhat reliably now, but it's still very clunky and awkward at best. Keep in mind I'm editing a large number of templates, so this could be a bit more edge case than most users. I do think that more designers would step up and help evolve the XF UI if it was easier to perform extensive template edits/re-writes.

For now, though, as who knows - it might be one of those changes that's so radical we might not see it this side of XenForo 2.0 - I recommend sticking with Cyberduck 4.3.x. That at least does still do the job nicely.
One of the usual suspects had an early implementation of file system templates already working on an older release of XF (I wish I could find the link). It slowed down page-loads while that mode was enabled.

Hope all is well with you :)

Cheers
 
Top Bottom