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
Refactored section edit #2220
Refactored section edit #2220
Conversation
At the moment the following things (still) work:
|
Wrong, some tests fail. I tested on a wrong directory, sorry. Will fix this. |
I got the following plugins installed: From that list I see the following plugins which would need an adjustment:
|
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.
This looks good already. I left a few comments, I think we can clean up the start/range/end handling a little.
inc/html.php
Outdated
if (!empty($matches['name'])) { | ||
$data['name'] = $matches['name']; | ||
} | ||
$data = json_decode($matches[1], true); |
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.
We probably need to catch some error here to avoid problems where for some reason the old syntax is still used.
I don't think json_decode throws proper exceptions, so we probably need to suppress the error and check if $data is null.
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.
Alternatively, we could adjust the pattern matching the syntax to include the opening and closing {}
of the JSON. That way we would ignore all old syntax.
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.
Is it likely that such errors can happen? I mean it is encoded in 'finishSectionEdit()', inc/parser/xhtml.php and decoded in 'html_secedit()', inc/html.php. I assume it could only happen if alternative renderers for HTML are used. Otherwise it is only DokuWiki core internal.
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.
Plugins might write their own section edit syntax to the HTML output without ever going through finishSectionEdit(). I don't know if any actually do though. I guess the easiest fix is to simply let the pattern look for the JSON delimiters.
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.
Ok, I did both: added the delimiters and checked for NULL anyway as a matching pattern alone cannot guarantee a proper JSON encoding.
inc/parser/xhtml.php
Outdated
* @param int $start The byte position for the edit start | ||
* @param array $data Assoziative array with section data: |
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.
typo: Assoziative -> Associative
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.
inc/parser/xhtml.php
Outdated
* Key 'hid': header id | ||
* Key 'codeblockOffset': actual code block index | ||
* Key 'start': reserved, do not use | ||
* Key 'range': reserved, do not use |
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 don't think these should be marked as reserved. Actually they are required, aren't they?
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 also wonder about having start
and range
. Shouldn't we have start
and end
instead?
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.
The $start
value is passed to startSectionEdit()
as an extra parameter. The $end
value is given to finishSectionEdit()
as an extra parameter. In finishSectionEdit()
finally the saved data['start']
value and given $end
value are used to build the range
. The range
is the important field that is sent on clicking on the section edit button. If that is not found then the section edit will not work. So, start and end are only temporary values and I thought it is better to put the calculation of the range into startSectionEdit()
and finishSectionEdit()
instead of having the caller calculating and assigning the range to the array. That means the keys start and range will always be overwritten. That's why I thought it would be good to mention them as reserved.
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 see. Maybe we can get the gist of that explanation into the doc block? Like:
'start': set in startSectionEdit(), do not set yourself
'range': calculated from 'start' and $key in finishSectionEdit(), do not set yourself
Something like that. I'm open for improvements on that.
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.
Sounds good, have used it.
public function startSectionEdit($start, $type, $title = null, $hid = null) { | ||
$this->sectionedits[] = array(++$this->lastsecid, $start, $type, $title, $hid); | ||
return 'sectionedit'.$this->lastsecid; | ||
public function startSectionEdit($start, $data) { |
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.
we probably need to check if $data is an array - old plugins may supply a type instead
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.
Ok, should we output a msg()
in such a case? Or a dbg()
message?
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.
let's do a msg()
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.
Done.
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'm currently trying to fix the Wrap plugin which is affected by this change. How can that be done in a backwards-compatible way?
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.
@selfthinker can you open a new ticket or mailing list discussion. Comments on a already closed PR get lost too easily.
To answer your question, you could inspect the SECEDIT_PATTERN definition maybe?
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.
@splitbrain: let me know if you want to merge it, then I can squash the commits to one single commit before the merge. |
@splitbrain: ping. Do you request any more changes to this? Let me now if it can be merged then I can squash the commits together before merging. |
squash ahead. there will be minor things only, if any |
The data for the section edit button is now passed as an assoziative array which is encoded in the '#<!-- EDIT(.*) -->#' placeholder as an JSON array.
0fc5659
to
ec57f11
Compare
Done. |
The signature of startSectionEdit was changed in dokuwiki/dokuwiki#2220 in a non backwards compatible way. This adjusts for that change in a way that should still work for pre-Greebo versions.
The signature of startSectionEdit was changed in dokuwiki/dokuwiki#2220 in a non backwards compatible way. This adjusts for that change in a way that should still work for pre-Greebo versions.
The data for the section edit button is now passed as an assoziative array which is
encoded in the '##' placeholder as an JSON array.
This also already includes the fix for issue #741.
This PR needs to be reviewed and it needs to be examined which plugins might need an adjustment.