-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate into media manager #246
Conversation
Implements michitux#209
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for this nice contribution! Overall this feature is a great addition to the plugin but I think error handling and permission checks need to be improved.
Also, this needs a protection against CSRF attacks. So a valid form token must be sent on the JavaScript side (could be copied from the delete button) and a form token check needs to be added in the ajax call handler.
action/rename.php
Outdated
if (file_exists(mediaFN($dst))) { | ||
$response['error'][] = $this->getLang('errorOverwrite'); | ||
} | ||
if (auth_quickaclcheck($dst) < AUTH_CREATE) { | ||
$response['error'][] = $this->getLang('errorPermissions'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moveMedia()
, or rather checkMedia()
, which is called by moveMedia
, currently performs the following checks:
- Source file exists.
- Delete right on source file.
- Source same as target.
- Target file doesn't exist.
- Upload right on target.
I don't see why these checks need to duplicated here. In particular, for all of these checks, there is already an error message including translations so this is basically adding duplicate code with duplicate messages. However, this is also missing some checks. Further, checking AUTH_CREATE
is actually wrong I think, this is for creating pages, for uploading media files you need AUTH_UPLOAD
.
The same is also true for errors that occur in moveMedia
itself. In fact, moveMedia
can even generate messages when the move itself succeeds but the old revisions cannot be moved. Will these messages be displayed to the user? I fear this is currently not the case but I think it would be good.
I think the easiest would be to just recover the generated messages from $MSG
, see inc/Ajax.php#L293-L297 for an example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I have removed the duplication and use the existing checks.
action/rename.php
Outdated
$dst = cleanID($INPUT->str('dst')); | ||
|
||
/** @var helper_plugin_move_op $MoveOperator */ | ||
$MoveOperator = plugin_load('helper', 'move_op'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems strange to me to start a local variable with an uppercase character, I've just searched for DokuWiki's code style but I couldn't find anything about this. Did I miss something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
if (actionList.querySelector('button.move-btn')) continue; // already added | ||
|
||
|
||
const moveButton = document.createElement('button'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to first check if the user can at least delete the media file at the source location? I think we shouldn't display a move button to user who can't at least delete the media file as otherwise the move operation will always fail. I think it should be possible to do this by checking if there is a delete button in the actions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I followed you suggestion and the code now checks for the existence of the delete button, which is only displayed when the user has sufficient permissions.
script/MoveMediaManager.js
Outdated
}, | ||
// redirect or display error | ||
function (result) { | ||
if (result.error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this rather check result.success
to detect if the move operation has actually been successful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
script/MoveMediaManager.js
Outdated
if (result.error) { | ||
const errorText = document.createElement('strong'); | ||
errorText.innerText = result.error.join(); | ||
errorText.style = 'color: red;'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be nicer to re-use the message box style that is usually used in DokuWiki for displaying error messages (if possible, I haven't checked if there is anything in it that wouldn't work in this dialog).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Custom style replaced with DokuWiki's typical <div class="error">
Media move is prevented if source and destination media files do not have identical extensions (strict comparison). UTF-8 names should be handled correctly if UTF-8 locale is set.
@michitux Thank you for your thorough review. I have pushed an additional commit that addresses the issues with media manager integration, and an extra commit with file extension check in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for addressing all my comments. I have one small remark regarding nicer error handling for the security token check, but that's also not really a blocker for me.
One more question: for the page rename button, there is the |
It makes sense to check the |
@michitux Is there anything I could improve in this PR or is it ready to be merged? |
I think overall this looks good, the only thing that could be improved is to hide the move button if the user cannot move files due to the |
Checks if user matches the 'allowrename' setting
0af31bb introduces an early check for |
Warning: Trying to access array offset on value of type null in ./dokuwiki/move/action/rename.php on line 42 $USERINFO is null when user is not logged in. Regression introduced by 0af31bb (michitux#246). Fixes michitux#256, michitux#255
Implements #209
A rename button is added to the file detail view in media manager. The user can enter the new destination in a popup dialog.
If the move operation does not return any errors, the media manager reloads the target namespace.