rwaight
commented
1 year ago Thanks for sharing the fix @cziehr. Just to clarify the code that causes the couldn't lock and will skip error is in lines 366-369 of admin.php, which is:
foreach((array) $data['lockfail'] as $id){
$this->_listOut($this->getLang('lockfail').' '.hsc($id),'error');
unset($synclist[$id]);
}I'm sure there is a reason that @splitbrain has this section in the code, but it would be good to have the option to skip that check.
For anyone looking for a fix to this (until a code update is made), you can either delete the lines listed above or make the following updates to admin.php (also available in this branch):
// allow read-only access to the remote wiki
// the below code causes sync to fail when the remote
// user only has read access to the remote wiki
// foreach((array) $data['lockfail'] as $id){
// $this->_listOut($this->getLang('lockfail').' '.hsc($id),'error');
// unset($synclist[$id]);
// }Once the update is made, you can start the synchronization again and should get a pull succeded response for the files.
This is also related to https://github.com/splitbrain/dokuwiki-plugin-sync/issues/51
If the user who is syncing has only read permissions on the remote wiki, the sync fails, because pages can't be locked.
I helped myself by commenting out the lines
foreach((array) $data['lockfail'] as $id){\ $this->_listOut($this->getLang('lockfail').' '.hsc($id),'error');\ unset($synclist[$id]);\ }
in lib/plugins/sync/admin.php
but this is rather quick'n'dirty and lost after every upgrade of the plugin.
It would be nice if the sync plugin recognizes when a page or a namespace is read only in the remote wiki and skips locking in this case - because locking isn't necessary when the page can't be edited.