Skip to content
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

Merged
merged 1 commit into from Mar 6, 2018
Merged

Refactored section edit #2220

merged 1 commit into from Mar 6, 2018

Conversation

lpaulsen93
Copy link
Collaborator

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.

@lpaulsen93
Copy link
Collaborator Author

At the moment the following things (still) work:

@lpaulsen93
Copy link
Collaborator Author

unit tests run without error

Wrong, some tests fail. I tested on a wrong directory, sorry. Will fix this.

@lpaulsen93
Copy link
Collaborator Author

I got the following plugins installed:
acl, authldap, authplain, bookcreator, cloud, creole, dw2pdf, feed, include, linkback, miniblog, pageimage, popularity, revert, text, authmysql, avatar, button, color, definitionlist, edittable, fields, mathjax, note, pagelist, publish, safefnrecode, tablewidth, typography, authpdo, backlinks, changemarks, columns, dir, emphasis, filelist, info, mathpublish, numberedheadings, pagelistng, randominc, searchstats, tag, usermanager, anewssystem, authpgsql, blockquote, chem, comment, discussion, extension, flattr, jabber, meta, odt, plugincheck, readability, styling, task, var, authad, blog, clippy, config, disqus, exttab3, folded, keyboard, mimetex, pagebreak, pluginrepo, switchpanel, testing, wrap

From that list I see the following plugins which would need an adjustment:

  • wrap
  • text
  • include

Copy link
Collaborator

@splitbrain splitbrain left a 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);
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

* @param int $start The byte position for the edit start
* @param array $data Assoziative array with section data:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: Assoziative -> Associative

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

* Key 'hid': header id
* Key 'codeblockOffset': actual code block index
* Key 'start': reserved, do not use
* Key 'range': reserved, do not use
Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator Author

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) {
Copy link
Collaborator

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

Copy link
Collaborator Author

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?

Copy link
Collaborator

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()

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@micgro42 fixed it and made it backwards compatible, and I opened a new issue for missing documentation (#2290).

@lpaulsen93
Copy link
Collaborator Author

@splitbrain: let me know if you want to merge it, then I can squash the commits to one single commit before the merge.

@lpaulsen93
Copy link
Collaborator Author

@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.

@splitbrain
Copy link
Collaborator

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.
@lpaulsen93
Copy link
Collaborator Author

Done.

@splitbrain splitbrain merged commit dfeb484 into master Mar 6, 2018
@splitbrain splitbrain deleted the sectioneditrefactor branch March 6, 2018 18:18
micgro42 added a commit to splitbrain/dokuwiki-plugin-data that referenced this pull request Apr 9, 2018
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.
saerdnaer pushed a commit to voc/dokuwiki-plugin-data that referenced this pull request Apr 16, 2018
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants