Tags:
create new tag
, view all tags

SectionalEditPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on SectionalEditPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Development discussion for SectionalEditPlugin

Feature Requests

Description Proposer StatusSorted ascending
Do not automatically break at each and every heading, make the depth configurable if possible. FranzJosefSilli Implemented
Maybe use variables for system-wide, web-wide, user-specific or topic-specific settings
Set EDITSECTIONS = 1 ( 0 ... turns of automatic break-up into sections)
Set SECTIONDEPTH = 2 ( 2 ... stop automatic break-up at heading level 2)
FranzJosefSilli Implemented
Expand the text before and after the edited section JohnCavanaugh Implemented
Integrate savemulti ThomasWeigert Implemented
Do not allow editing of form when editing section (the form is associated with the topic, not the section) ThomasWeigert Implemented
Text of sections not being currently edited should be rendered normally   Implemented
Allow user defined styles for editable sections beyond the "bar on the side" style. ThomasWeigert Implemented
Allow user to add a tag to a topic specifying that this page should not have sectional editing enabled (used when it's on by default)
Or, have open and close tags to define a page region that should not have section editing enabled
ChrisRiley Implemented
Deprecate startRenderingHandler. Support render script from CacheAddOn. Rely on use strict JacekZapotoczny, MeredithLesly Implemented
Remove sections from "Printable" view. "Edit" links and borders around sections are unnecessary on paper. JacekZapotoczny Implemented
Would it be possible to define some meaningful default values for SECTIONDEPTHMIN and SECTIONDEPTHMAX ? If someone installed a plugin and didn't define SECTIONDEPTHMIN and SECTIONDEPTHMAX yet,the behavior is very non-intuitive. It feels very confusing because <editsections/> doesn't work at all (no edit link) but there is no error message etc. It simply doesn't work, from user's point of view. JacekZapotoczny Implemented
headers declarations with over 3 dashes (e.g. ------++) are parsed as headers and not treated as editable sections. Needs to be consistent with TWiki --TW JacekZapotoczny Implemented
Sections are disabled in Printable mode only if you add viewprint to SKIPSKIN variable. I think it should be added there by default. JacekZapotoczny Implemented
Show sections in preview mode JacekZapotoczny Implemented
Evaluate the ScripSuffix, so the plugin will also run on webservers which require an extension (e.g. .cgi or .pl). I changed line 149 from:
my $eurl = TWiki::Func::getScriptUrl() . "/editsection.pl/$web/$topic";
to:
my $eurl = TWiki::Func::getScriptUrl() . "/editsection" . "$TWiki::cfg{ScriptSuffix}" . "/$web/$topic";
In this example I also changed the deprecated getScriptUrlPath() to getScriptUrl()
(see http://twiki.org/cgi-bin/view/TWiki/TWikiFuncDotPm#get_ScriptUrlPath_path)
MartinMayer Implemented
Make PlugIn compatible with TWiki 4.2 MartinSeibert Implemented
Concurrent editing of different sections VickiBrown  
Ability to place a link or include to a something (e.g. formatting guide) just above the editsection in the edit mode    
Automatic edits for %INCLUDE JohnRouillard  
Add a "tooltip" message to the editsection link LynnwoodBrown  
Allow preference for heading level below which SectionalEditPlugin applies. Perhaps expand syntax of SECTIONDEPTH to allow definition of upper and lower depths. LynnwoodBrown  
Would it be possible to add a "Add Note" button next to the "Edit" button. Essentially, I am looking for a way for a reviewer to leave comments scattered around the page which the main author can then incorporate in a future revision. The comment could be rendered as a Post-It note (next to the section heading, or overlaid on the text; simple with a little bit of CSS). Ideally, one would like to add notes anywhere on the page (and have them popup on hover/click like Excel notes). However, providing the ability to add/delete notes on a per-section basis would be a great start. Check out StylePluginDev for a very simple CSS to generate PostIt-like notes. It can be made to look much cooler, but this can be a start. The thing I would really like to see are buttons on each note to Edit and Delete them. PankajPant  
The ability to turn on sectional editing for a topic (or an entire web), but with the option to turn it off per section. KeithHelfrich  
Do not show section markup (e.g., dotted lines around sections) in printable view. Alan Pietch  
If the section before the first heading is empty in <editsections/> mode, then do not show a section there. We can always insert text before the first heading by editing the section of the first heading. ThomasWeigert  
After a section save browser should show the section and not the top of the page. It would ease work with long documents which SectionalEditPlugin is designed for(?). This is a great idea, but not so easy to implement as this requires an anchor in the document; this anchor would have to be newly created each edit, so it also needs to be deleted again to avoid proliferation. I'll try if I can pick up the anchor when going into edit, and recreate it upon save, and then redirect to that anchor. --TW
Since sections are typically starting with a header and that TWiki generates a name/id for every header we should be able to use it. That should handle the most common use case.
--SL
JacekZapotoczny, StephaneLenclud  
Compatibility with ExplicitNumberingPlugin MikkoLaakso  
Put edit link in to headings CarloSchulz  
Allow topic-specific EDITSECTIONS but hide from view when editing topic (e.g., could be done in topic actions and stored in metadata) ThomasWeigert Possible using view templates.
Do not put <editsections/> into its own section if it is the first entry of the topic. Answer: The tag can go anywhere, so placing it after the header will not create a separate initial section. FranzJosefSilli Rejected

Discussion

Very interesting plugin. Im now thinking about how it could be used in conjunction with TWikiPhotoAlbum plugin, and a NavPlugin, to allow easy navigation of an image gallery and allow folks to make individual comments on particular images. Hmm...

-- JohnCavanaugh - 06 Feb 2003

Some people had questions they posted to the test topic. Here are my responses:

... Shouldn't the non-edited text be rendered as normal?
I kept it in non-rendered form to facilitate cut/copy/paste operations. I'm thinking of adding a preference variable to allow you to have it one way or the other though.
Now shown in rendered mode -- TW
Why is a closing break marked with a fore-slash at the end of the tag instead of at the beginning like other *ML markup?
It's because TWiki plugins are expected to use XHTML and the sectionbreak tag doesn't need a closing tag so it "closes itself" as it were.

-- DanBoitnott - 07 Feb 2003

Sectional edits look interesting, but what is the purpose? To eventually allow multiple simulataneous edits? Or simply to make small edits like fixing typos easier? Something else I'm not thinking of?

-- MattWilkie - 07 Feb 2003

I don't know what everybody else will use it for but I wrote it because my users were complaining about editing large (by large I mean 600 page) topics. You find what you want to edit, scroll to the bottom, then have to find the spot you want to edit again. In a normal topic this isn't a problem, but when we're putting together legal complaints with large timelines we needed a way to reduce user pain. In it's current implementation it absolutely must not be used for simultaneous editing because it would not save both edits.

Also, see above for JohnCavanaugh's ideas about how it might be used.

-- DanBoitnott - 08 Feb 2003

Okay, I certainly see how it would make editing very large topics easier. WRT, to the issue of having to scroll down to the bottom in order to start an edit session, may I point your attention to AccessKeys? With a keyboard shortcut to Edit ,scrolling in order to access topic actions is unecessary. I am very much addicted to them.

-- MattWilkie - 08 Feb 2003

Hmm. Neat.

I wonder if we can use a similar idea to allow fast editing of documents made up of included topics. Something like:

%INCLUDE{"WikiTopic" edit="yes"}%

would render a bar and edit link.

Also the grey section bars and edit links are used as navigation aids when changing the topic. If the print skin is being used, these items IMO should not be rendered.

-- JohnRouillard - 09 Feb 2003

Also, I think it would be a neat idea to have a little "edit your included topic" thingy. I think it would take some work in the TWiki core though because that's where includes are handled. You can however set one up manually. It's much more tedious but it works. Here's some demo code:

<table border="0" width="100%"><tr><td width="0%" bgcolor="silver" align="right" valign="top"><a href="../../edit/Test/DemoIncludeTopic">Edit</a></td><td width="100%" align="left" valign="top"> %INCLUDE{"DemoIncludeTopic"}% </td></tr></table>

I've put this example on my site here.

-- DanBoitnott - 09 Feb 2003

Very useful plugin. To be able to use "Edit" button along with INCLUDE, I think one may have to change INCLUDE. One could put the section edit tags within the included topic. But, I would like it to be associated with INCLUDE itself. Not sure how this could be done - unless we change code for INCLUDE. And it is not under plugin.

Also, we need some standard way to control these aspects (This is common to CommentPlugin or EditTablePlugin):

  • Style of "Edit" button. (Images etc.)
  • Location" of the "Edit" button. Ideally, I might want to put a edit button even outside the area rendered. This is specially the case in Portals - where the box has "edit" button on right hand side corner. (And this requirement will mean that the section needs to be named - see my comments in RecursiveRenderPluginDev.)
  • Style of rendered information. This is easy - enclose it in "div" and associate a CSS class with it.
-- VinodKulkarni - 09 Feb 2003

"Style" of the edit button can be controlled with this plugin using the BGCOLOR and LABEL preference variables. BGCOLOR sets the background color of the edit bar. LABEL sets the contents of the edit bar. LABEL can be set to anything, including an IMG tag.

As to location of the edit bar, I'm open to anything but would want more detail on what you're after. Are you wanting a sort of "left, right, top, or bottom" sort of thing or something more detailed?

I'm not sure I understand what you mean by "Style of rendered information." Are you refering to the contents of the sections? These would be controlled in the same way you control the style of a normal topic.

-- DanBoitnott - 09 Feb 2003

The editsection script does not expand the pre & post text (This is really a needed behavior especially for edit section, but Im hoping someone else fixes that little bugger, hint hint...)

-- JohnCavanaugh - 25 Mar 2003

I'm not sure I understand what's meant by: "The editsection script does not expand the pre & post text"

I think it means that the text that's not being edited is not rendered. I left it that way for two reasons:

  1. To facilitate copy/paste operations from other sections
  2. Because it's easier to code that way
I do recognize however that if you're using it in conjunction with the EditTablePlugin like John, you probably would prefer to have the rest of the table rendered as normal. If that's the case perhaps we could put a parameter in the tag or on the plugin preferences page. Thoughts?

-- DanBoitnott - 11 May 2003

I attached a new version of SectionalEditPlugin (hope you dont mind Dan...) that includes a fix for the double-quote problem that had been plaging folks. It also fixed a more rare problem with "---+++ Items" as the first line in the first section.

-- JohnCavanaugh - 22 Sep 2003

I've added SectionalEditPlugin to the twikiplugins CVS (See twikiplugins on SourceForge).

  • The latest versions are not in CVS -- TW
Attached is a version with some new features (and probably some new bugs!). I would be grateful if you could try it and let me know any bugs and so forth. Features added are:
  • Custom edit width / edit height / edit style (defaults to same as ordinary edit)
  • BGCOLOR is now interpreted so you can set it to be the same as %WEBBGGOLOR% if you like.
  • Edit bar can be left or right justified
  • Added <editsections/> tag which automatically splits on section headers ---+
  • Updated bin/editsection program and templates. Please check for any problems.
-- JohnKnottenbelt - 30 Mar 2004

Repackaged my tweaked version below. Just exchanged old (obsolete) function calls with the appropriate new ones to make it work with Cairo. Did not manage to make the template files compatible to the PatternSkin yet.

-- FranzJosefSilli - 24 Jan 2005

I made the following adjustment to editsection.pattern.tmpl template: Moved the %POSTTEXT% after the topic actions. This brings the topic actions as close to the edited text as possible and avoids having to scroll down through the %POSTTEXT% for the save button.

-- FranzJosefSilli - 28 Jan 2005

I was wondering regarding the form fields. Is it really appopriate to edit the form data as part of editing the sections? In a sense the form is a property of the whole topic (personally I think it is a separate TWikiApplication), while the sections are part of the topic. Maybe the form should be edited only when the whole topic is being edited?

-- ThomasWeigert - 30 Jan 2005

You're right about form fields: doesn't make sense to have form fields within sections as long as we don't have MultipleFormsPerTopic

-- FranzJosefSilli - 01 Feb 2005

I wonder whether EDITSECTIONS (or <editsections/>) shouldn't be part of the metadata of the topic, rather than a global setting? Certainly it does not belong into the topic text, as FranzJosefSilli pointed out earlier.

Refactored this topic and deleted outdated comments above.

-- ThomasWeigert - 12 Feb 2005

Implemented a number of earlier requested features:

  • Added EDITSECTIONS preference variable with the same effect as inserting an <editsection/> tag in every topic. This variable can be set in either the user or web or twiki preferences topic. This makes this plugin less obtrusive.
  • Added SECTIONDEPTH preference variable controlling the depth to which headings are grouped into sections.
  • Integrated savemulti. The plugin is now fully compatible with cairo and patternskin.
  • Render the text before and after the section being edited, rather than showing the raw text. In particular, where that text has fancy formating (such as %EDITTABLE%) this makes the text much more readable. All links in the pre and post text are treated as if in preview mode.
-- ThomasWeigert - 13 Feb 2005

thanks for your work on this Thomas. I'm looking forward to trying it out.

-- MattWilkie - 13 Feb 2005

Updated SectionalEditPlugin to not open editing of form when editing sections. In other words, when you edit a section, you just focus on that one section, nothing else.

-- ThomasWeigert - 28 Feb 2005

First a small suggestion: to add a title attribute for the editsection link along lines of "Edit this section." I added it myself but, of course, lost it when updating the plugin. (I'm resolving to restrain myself from adding these kinds of tweaks locally that I then have to maintain.)

Now a question: does the sectiondepth preference allow for designating upper and lower depths? In other words, can I tell it to add editsection only on levels 2 to 4? I noticed there's no instructions on the plugin topic regarding sectiondepth - so if you can clarify the specs, I'd be glad to add this bit of documentation. Just a small thing to help with your great work here.

-- LynnwoodBrown - 11 Mar 2005

Lynwood, I am not quite sure what you mean by the "title attribute for the editsection link". Can you explain in more detail? You could just add this to the feature request table above...

To answer the question re section depth... as currently implemented depth refers to the level to which editsections are inserted. Setting this to 0 means all headlines create sections. Setting this to 1 means that everything below a h1 heading is an editable section. Setting this to 2 means everything between an h1 and an h2 heading is an editable section, and everything below an h2 heading is an editable section. And so on...

-- ThomasWeigert - 11 Mar 2005

I was merely suggesting adding a "tooltip" message to the editsection link. I implemented by changing line 71 of SectionalEditPlugin.pm to read as follows:

return "<a href=\"$eurl\?t=" . time() . "&sec=$pos#SECEDITBOX\" title="Edit this section" ><small>$title</small></a>"; 

A minor thing really, hardly worth listing as a "feature request."

Thanks for the additional info on the levels. I'll play with it some to make sure I'm clear on how it works and then add details in SectionalEditPlugin topic.

-- LynnwoodBrown - 11 Mar 2005_

Added a draft revision of SectionalEditPlugin#Syntax_Rules.

Would also note that since I upgraded to the 08 Mar version of the plugin, once again the new line prior to headings is being dropped.

-- LynnwoodBrown - 13 Mar 2005

Lynnwood, thanks, I'll include your doc update in the next release.

-- ThomasWeigert - 13 Mar 2005

( Much discussion regarding a bug deleted as this has been resolved now.)

Several reports of problems with several browsers other than IE or Opera (in particular Firefox):

  • Still one little annoyance: the header of a following section gets mixed up if one doesn't add another return ( \n) -- FranzJosefSilli - 03 Feb 2005
  • There's a problem in the version which you can download today: if you save a section starting with a header (say ---++), the result is that the section starter sequence does not get on its own line, thus loosing its meaning. the cure is putting a '\n' at the beginning of the edited section. -- MarioFrasca - 17 Feb 2005
  • There appears to be a serious bug in this plugin. Consider the following Wiki text... Which is totally cluttered and does produce wrong renderings. I am using the latest released TWiki version and the newest SectionalEditPlugin (though the error appears also with older versions). -- GuidoOstkamp - 28 Feb 2005
  • Just wanted to submit another report of bug discussed above. With a brand new install of Cairo release and SectionalEditPlugin (27 Feb 2005), every time I edit a section and save, it deletes the return prior to the section heading resulting in the "---+" being at end of prior paragraph. I didn't have time to test extensively but did reproduce problem in both Safari & Firefox on Mac. -- LynnwoodBrown - 28 Feb 2005
Several variations of a fix were proposed by MarioFrasca which I was not comfortable to include as they either
  • Changed the text that the user had typed into the edit box, or
  • Seemed ad hoc solutions based on observed current behavior of browsers rather than the W3C standard, and
  • Were inconsistent with the treatment of URL parameters elsewhere in TWiki and in EditContrib.
The first two of these remarks do not apply to the last fix, with regards to the last remark, the treatment of CDATA in UI is currently under discussion in InconsistentTreatmentOfTextEncoding and may change in a future release of TWiki. -- 22 Mar 2005 MF, text in emphasis edited by TW

This bug pointed to several other issues regarding URL parameter passing in TWiki which are discussed at InconsistentTreatmentOfTextEncoding and SomeBrowsersLoseInitialNewlineInTextArea.

While the problem seems to be avoided by bracketing passed text with non-newline characters, per the W3C recommendation, we should not be passing any newlines in the other form fields (e.g., the "hidden" inpt field), leading or not. In fact, it appears that browsers are entitled (albeit they do not have to) drop newlines from all fields but "textarea".

In my opinion, we cannot implement a solution that is subject to arbitrary implementation decisions by various browser vendors. I therefore have implemented a solution that will work no matter how the browser vendors did this and no matter how they will change their mind in the future. This required a change to EditContrib as well as SectionalEditPlugin.

I have verified that the behavior is correct with IE and Firefox (both on Windows XP).

-- ThomasWeigert - 20 Mar 2005

from the last version of the fix:

+    if ($alsoCR) {
+   $text =~ s/\n/%CR%/go;
+    }

admittedly, the correct name for that boolean was $forCDATA, it should have included \t characters, could have used the same encoding as in other parts of TWiki.

bracketing was an other working option. having read the W3C recommendations, I do not sustain it any more.

-- MarioFrasca - 23 Mar 2005

I am using the 21 Mar Versions of SectionalEditPlugin and EditContrib. Although now working fine even with Firefox, there is a problem with rendering during edit of a section: Bullet and numbered lists do not render at all. They result in plain text without even a line break.

However, if I insert the following in EditContrib.pm
271: $pretxtRender =~ s/ {3}/\t/go;
and
284: $postxtRender =~ s/ {3}/\t/go;
The lists are rendered correctly as List, with the exception that RenderListPlugin commands are ignored

The lines I inserted are taken from the code of the preview script. Since I have only little knowledge of perl, I can't say if this change is correct or not and what side effects it has.

I'm running TWiki engine: 02 Sep 2004 $Rev: 1742 $ on W2K with mod_perl, and using PatternSkin

-- DanielSiegenthaler - 06 Apr 2005

Daniel, thanks so much. I assume that you are referring to the rendering of the text before and after the section being edited, during the edit process?

This has been corrected and a new version of EditContrib has been issued.

You can test this at the referenced web site. RenderListPlugin commands are rendered also.

-- ThomasWeigert - 07 Apr 2005

What are the allowable values for the BGCOLOR setting? I tried 'white' and 'blank' but it's still rendered as silver. (sorry if this should be in support...)

-- JosMaccabiani - 07 Apr 2005

You can put colors there using the standard color scheme, twiki color variables, or the standard labels, such as black, white, etc.

Please look at the referenced web site where I set the color to red....

-- ThomasWeigert - 08 Apr 2005

Sorry to bother you here, but i looked at your referenced website, where the background of the TWiki sectional edit links is red in sted of silver.

However, in WebPreferences I only see:

a.. SectionalEditPlugin
   a.. Set EDITSECTIONS = 0
   b.. Set SECTIONDEPTH = 2

...so no BGCOLOR information (I also couldn't find any in TWikiPreferences)

Sorry, this is probably a stupid question, but I'm just starting to fiddle with TWiki.

-- JosMaccabiani - 07 Apr 2005

Jos, there are several places where you can put plugin configuration. Usually these are in the Plugin topic, as is the case here. Please look into the TWiki.SectionalEditPlugin topic...

-- ThomasWeigert - 08 Apr 2005

Thanks a bundle! It hadn't dawned on me that the settings in the Plugin topic would take precedence. It works like a charm now.

-- JosMaccabiani - 07 Apr 2005

I have updated the SectionalEditPlugin by allowing a style property. This gives the user the ability to define custom rendering for the editable sections rather than the standard bar on the side. For example, by setting the style as in the plugin topic, a dotted red outline is drawn around editable sections. One can also associate styles with the individual <sectionedit> tags...

-- ThomasWeigert - 13 Apr 2005

Hi Thomas, there is apparently a caching issue with SpeedyCGI and this plugin and MultiEditPlugin. See my comment on EditContribDev (same date as this comment).

-- MarcusLeonard - 01 May 2005

Fixed the caching issue discovered by MarcusLeonard.

-- ThomasWeigert - 03 May 2005

Would it be possible to add a "Add Note" button next to the "Edit" button. Essentially, I am looking for a way for a reviewer to leave comments scattered around the page which the main author can then incorporate in a future revision. The comment could be rendered as a Post-It note (next to the section heading, or overlaid on the text; simple with a little bit of CSS).

CommentPlugin provides rudimentary support for this usage model. However, this feature would make it much more intutive for anyone who is scared of/unfamiliar with TML. There are many managers who resent TWiki, since it is not easy for them to do the simple things that they have been used to in the past (comments are well supported by MS Word and Excel).

Ideally, one would like to add notes anywhere on the page (and have them popup on hover/click like Excel notes). However, providing the ability to add/delete notes on a per-section basis would be a great start. SectionalEditPlugin already allows a page to be divided by sections which is why I am posting this here.

Any thoughts?

-- PankajPant - 03 May 2005

This is a good idea... maybe I'll make a postit-note plugin... If you can provide the CSS for the overlay of the "postit note" I will to the rest...

-- ThomasWeigert - 17 Jun 2005

Sorry, I never noticed this request even though I've been to this topic many times since. Check out StylePluginDev for a very simple CSS to generate PostIt-like notes. It can be made to look much cooler, but this can be a start. The thing I would really like to see are buttons on each note to Edit and Delete them.

-- PankajPant - 25 Sep 2005

I just (re) installed the latest version of this plugin. Great work! I think the dotted lines are much more intuitive (i've just made them a little lighter, #FFE5F9 on white background).

A suggestion for very slight improvement: could the 'edit' link be placed just inside the box? sometimes it's not immediately clear to which section it belongs.

Great Plugin!

-- JosMaccabiani - 10 Jun 2005

I patched the 03 May 2005 version of the SectionalEditPlugin to add a popup support (SectionalEditPlugin-AddonPopupPatchv1.zip).
When you click on an edit section link, this patch allows to open a popup which contains only twiki source of this section and keep the topic view in background. On each action, the topic view is refreshed and you can see immediately your changes.
In addition, a confirm message appears to ask you if you want to save your changes before exit if the section has been edited and the popup closed.
Also, I edited the sections algorithm (works only with the tag <editsections/>...). Now, each section, created starting from a level of headings, includes its lower levels of headings.

In the futhur, I'll correct the following behaviors which have to be improved:

  • If an error occurs during the Edit/Save (example:oops message for lock), the default oops message appears in the popup. it would be interesting to be able to redefine the oops message.
  • For the moment, on save the popup is directly closed. It'll be necessary to check it and in this case to display it (the new oops message...).
  • close + confirm save, view topic often no refresh. You have to make manually a hard refresh.
Thank you by advance for your remarks and/or your suggestions.

-- FredericLuddeni - 17 Jun 2005

When the plugin is installed, all the result blocks of the search results page from SearchEnginePluceneAddOn show an 'edit section' link.

Since there are no headings (i defined the section edit depth to be 2) I figure the plugin looks at some DIV tag? Which one?

-- JosMaccabiani - 07 Jul 2005

Jos, if you have the EDITSECTIONS preference set, then the plugin will look for the following regular expression: /^---\+{1,$sectiondepth}[^+]/mg , that is, three dashes followed by up to the number of plus signs as you have SECTIONDEPTH set, but at least there needs to be one plus. Look in your output from SearchEnginePluceneAddOn without the SectionalEditPlugin enabled. I would venture that you will find that pattern there...

-- ThomasWeigert - 09 Jul 2005

checked .zip into CVS

-- WillNorris - 19 Jul 2005

Updated version. Please also download the updated version of EditContrib.

-- ThomasWeigert - 04 Aug 2005

I've attached a patch to allow you to disable Sectional Editing within a topic. Use this if you have it turned on by default, but want to turn it off for a topic (say, because you have section breaks inside a table).

-- ChrisRiley - 18 Aug 2005

Does this plugin work on Develop yet? I still see this a must for my future TWiki server.

-- FranzJosefSilli - 29 Aug 2005

Franz: I have the same problem, as I need to edit only a section of a topic in a TWikiApplication using DEVELOP. I'm a little pressed in time so I didn't try to migrate EditContrib to Develop, instead I hacked together just the fucntionality I needed. See attacched file EditSectionPlugin. You can specify sections using the <section id="name"></section> tags. Each section is edited in place.

Hope this help

-- RafaelAlvarez - 31 Aug 2005

Has anyone given any further thought to the idea suggested by PankajPant on 03 May 2005 to create a sectional comment facility?

I have been thinking that something like this would be useful, particularly if the section based comments were written to another topic and then rendered back into the original topic perhaps using a different skin. Enabling the topic to be viewed with/without comments.

-- ChrisSBrown - 06 Sep 2005

Just installed this plugin version "4 Aug 2005". I usually use the <editsections/> tag on the first line of a topic to enable the plugin on a per-topic-basis.

In doing so, an edit link with sec=0 appears with empty content. Actually, it does contain something namely the editsections tag but it is suppressed for editing. I guess it should also be suppressed for rendering to take advantage of the ... unless ($sec =~ /^\s*$/o); detection of empty sections.

So I applied the following change:

-my $editsections = 'EditSections' if (($alwayssection && $_[0] !~ /^\s*<body/is) || ($_[0] =~ m%<editsections\s*/>%i));
+my $editsections = 'EditSections' if (($alwayssection && $_[0] !~ /^\s*<body/is) || ($_[0] =~ s%<editsections\s*/>%%i));

-- DanielKabs - 16 Sep 2005

The rss skin should be added to the default SKIPSKIN list. I did that on the plugin page, but in case that isn't carried back to SVN, I'm hoping this note will catch a future modifier's attention.

Also, can this plugin be turned off for non-view scripts? It is pointless, for instance, to mark sections in an rdiff listing for editing. Unfortunately, rdiff isn't a skin.

-- DavidBright - 01 Nov 2005

As DavidBright suggests, this plugin doesn't need to be invoked by scripts other than viewing scripts. If you agree then apply the following one line change (please excuse any perl or patch style crimes as this is my first):

*** lib/TWiki/Plugins/SectionalEditPlugin.pm.old        2006-02-01 08:21:58.937265448 +0000
--- lib/TWiki/Plugins/SectionalEditPlugin.pm    2006-02-01 08:20:38.041563464 +0000
***************
*** 141,144 ****
--- 141,147 ----
      # This handler is called by getRenderedVersion just before the line loop

+     # Only bother with this plugin if viewing (i.e. not searching, etc)
+     return unless ($0 =~ m/\/view|\/viewauth/o);
+
      my $cskin = &TWiki::Func::getSkin();
      my $skipit = 0;

-- KarlSkidmore - 01 Feb 2006

This plugin doesn't seem to work in 4.0.1. After inserting the various sectionedit tags and saving the topic, the section edit link doesn't show up. I can see the hr and edit link in when I look at the page history, but when I click on the edit link from the page his, I get this error:

Can't locate TWiki/Contrib/EditContrib.pm in @INC (@INC contains: /home/httpd/twiki/lib/CPAN/lib//arch/ /home/httpd/twiki/lib/CPAN/lib//5.8.4/i386-linux-thread-multi/ /home/httpd/twiki/lib/CPAN/lib//5.8.4/ /home/httpd/twiki/lib/CPAN/lib// /home/httpd/twiki/lib . /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl) at editsection line 37.
BEGIN failed--compilation aborted at editsection line 37.

-- RyanKnoll - 24 Feb 2006

Sorry Ryan, ThomasWeigert seems to be too busy to update his very valuable Plugins and AddOns to 4.x at the moment. I'm too less of a programmer or I already would have updated EditContrib and thus Thomas' Plugins, cause they relay on it. Hopefully there will be someone more skilled jumping on this soon.

-- FranzJosefSilli - 24 Feb 2006

It's on my priority list, too. I took a crack at upgrading the plugin(s), but there are significant conflicts between SVN and the attached release versions that I have yet to sort out.

-- ScottHoge - 24 Feb 2006

Thanks Scott for jumping in. Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase as described in HandlingCairoDakarPluginDifferences.

-- PeterThoeny - 24 Feb 2006

That's great news!

-- FranzJosefSilli - 25 Feb 2006

Yes, please! Of all the remaining non-Dakar-compatible plugins, this one stands out for us as the most important. We use a lot of TWikiApplications where editing the whole page is very undesirable. (If anyone can get the WysiwygPlugin to fit into it I'll send you flowers. Or something useful.)

-- MarcusLeonard - 03 Mar 2006

Checked a few changes into SVN just now. Everything is running on Cairo, and functional (BUT NOT COMPLETE!) on Dakar. At a minimum, forms are not rendered and the edit preview will throw an error. Need to update both this plugin and EditContrib.

(developing ... )

-- ScottHoge - 06 Mar 2006

Is it correct that editsection.tmpl in this package is meant to overwrite the same file in EditContrib? (I'm looking at the SVN versions).

-- SteffenPoulsen - 08 Mar 2006

There should probably be only one editsection.tmpl. wink I was using the version from EditContrib during testing. I thought I had caught all of these SVN vs. release discrepancies. Guess I missed one. Thanks.

-- ScottHoge - 08 Mar 2006

I was wondering if my setup is wrong or if there is another issue at work.

The problem I have is that I get a Permssion Denied when I use the sectionedit tags, even though I give the user/group permssion for ALLOWTOPICCHANGE.

To clarify, I had a little sandbox, where the topic change was restricted to a very small group. I went in as a user in that group and when I clicked edit, I got the message: You do not have permission to change topic ...

Is this an issue with the plugin or my configuration? Thanks!

-- EricHanson - 05 May 2006

Can you edit the topic normally?

-- ScottHoge - 05 May 2006

Yes, I can edit the topic normally and I have partly solved my problems. I did not follow the install instructions and failed to modify the .htacces file appropriately.

So I can get to the edit screen, but I get a message when I try to save: Change Access Denied

Update

I had a custom perl that the savesection should have been pointed to. Didn't see any perl warnings/errors in the logs though, that it could find anything. My auth setup uses some custom modules that are only in the custom perl. Don't know if this problem will ever apply to anyone else.

-- EricHanson - 08 May 2006

I have moved this plugin plus its supporting EditContrib to Dakar. I will now integrate the patches and improvements discussed above.

Just a word of caution: There is a known problem in that if the last character in a section is a TWiki markup, the markup will be rendered verbatim. Nevertheless, due to many requests I have put the plugin here without having addressed this final issue.

-- ThomasWeigert - 12 Jun 2006

Updated with some fixes.

-- ThomasWeigert - 13 Jun 2006

We've been using the SectionalEditPlugin (on Cairo) for ages without problem and the people at my company love it. So much so that it is on by default using the Set EDITSECTIONS = On preference in TWikiPrefences. All was well until I installed the TreeBrowserPlugin, which we now use in the WebLeftBars and WebLeftBarWebsList (which people also now love). Once these two plugins are installed together and the EDITSECTIONS preference is set, the section edit links stop being rendered. A workaround is to disable the EDITSECTIONS preference and add <editsections/> to individual topics. We've got oodles of webs and thousands of topics (so I just don't want to do this). I spent hours trawling through the code of this plugin and cannot get my head around the problem.

The code below is from SectionalEditPlugin.pm around line 157. $alwayssection is set from the EDITSECTIONS preference and if that is not set then the <editsections/> is searched for. So why would disabling the preference and adding <editsections/> to the topic text make any difference? I've no idea but it seems to make a difference.

Is anyone using these two plugins together (with EDITSECTIONS preference set) and without problems?

    unless($skipit) {
        my $editsections = 'EditSections' if (($alwayssection && $_[0] !~ /^\s*<body/is) || ($_[0] =~ m%<editsections\s*/>%i));
        my $noeditsections = 'NoEditSections' if ($_[0] =~ m%<noeditsections\s*/?>%i);
        # <sectionbreak/> inserts break in sections, <editsections/> sections all.
        # why did we also use <sectionbreak/> in the first line to section all?
        # Make sure space before /> is allowed also in the script
        my $sectionbreak = 'SectionBreak' if ($_[0] =~ m%<sectionbreak\s*/?>%i);
        # Why is the /> possible?
        my $sectionedit  = 'SectionEdit' if ($_[0] =~ m%<sectionedit.*?>%i);
        my $activate = $editsections || $sectionbreak || $sectionedit;
        $activate = 0 if $noeditsections;

-- KarlSkidmore - 13 Jun 2006

Karl, can you please try to change the line that initializes editsections above to

   my $editsections = 'EditSections' if (($alwayssection && $_[0] !~ /\<body/is && $_[0] !~ /\<\/body\>/is)  || ($_[0] =~ m%<editsections\s*/>%i));

and let me know whether that makes any difference?

-- ThomasWeigert - 13 Jun 2006

The Dakar port has a known problem: verbatim and pre sections are not rendered in view mode (they are saved correctly). The reason is that a new handler ( preRenderingHandler) needs to be used on Dakar. Will get to that soon, hopefully.

-- ThomasWeigert - 13 Jun 2006

(psst) check SVN.

-- ScottHoge - 13 Jun 2006

Thanks for your help Thomas. I made the change, no joy unfortunately. Please see screen shots uploaded here: KarlSkidmore#TreeSectionIssue which explain the situation further.

-- KarlSkidmore - 13 Jun 2006

Bad news, Karl. I figured out what is going on: all plugins are invoked whenever TWiki::Func::renderText is called on some text, and so, if edit sections are turned on, that text is subject to also the SectionalEditPlugin. In normal situations that does not matter, but in the case of the items generated by the TreeBrowserPlugin, that processing interferes with the Javascript generated by that plugin.

However, I cannot see any way of recognizing when we are processing the top level of the page, and when we are processing just some string of text. The SectionalEditPlugin needs to kick in only in those occasions.

The only way I could see this being avoided is if we would not generate editing for the text before the first section, but that would not work in the normal cases.

The reason why this problem does not occur with <editsections /> is that in those cases we do not process text that does not have such label. But when you turn on the plugin globally, every text is processed.

The lesson here is that Plugins need to be able to register with handlers in a way that they are not invoked when they are not needed or can cause damage.

My conclusion at this point, but I will investigate some more, is that the option of turning sectional editing on globally, is not a good one as it might have these unwelcome interactions with plugins that generate Javascript.

-- ThomasWeigert - 17 Jun 2006

Thomas - have a look into svn, at InlineEditPlugin. I've made some attempts at limiting the applicability of its section generation using twiki 4 contexts, skins and other bits. You and I are duplicating work here, but its useful to share smile

-- SvenDowideit - 17 Jun 2006

Thomas - Thanks again for looking into this. I had a hunch it would be as you described (but I wasn't familiar enough with the code to confirm it) and so had previously attempted - in vain - placing <noeditsections/> in the included topics that used the tree plugin. Thanks again.

-- KarlSkidmore - 17 Jun 2006

Karl, I just had an idea. I think we can make this work, but I won't get to it for a couple of days...

-- ThomasWeigert - 18 Jun 2006

Actually, I found some time. Karl, can you please try this:

In the section that starts with

       if ($editsections) {

put after the while loop going over all section markers the following:

                return if ($lastpos == $pos);

This worked for me on your test cases. Note that if you are turning edit sections on all the time, you might want to protect oops dialogs and similar from having editable sections inserted...

-- ThomasWeigert - 18 Jun 2006

Thomas, that worked - Thankyou very much! FYI, this has also fixed a problem with the HolidaylistPlugin, which I previously got around with a rather hacky return if(length($_[0]) < 30); near the top of startRenderingHandler(). Thanks again!

-- KarlSkidmore - 18 Jun 2006

Sven, I'll look at what you did.

Just a question... is there a reason why this is not in the normal developbranch SVN? Further, the *.txt file speaks of a dependency on a ComponentEditPlugin, but that cannot be found... is that really needed?

-- ThomasWeigert - 18 Jun 2006

One suggestion on the doc: in step 4 of the installation instructions, mention {AuthScripts} in configure as possible alternative to .htaccess file.

Thanks, Thomas, for updating this plugin for Dakar! I've been missing it.

-- LynnwoodBrown - 20 Jun 2006

Any suggestions for how to mock up a editsection.koala.tmpl for using this plugin with the KoalaSkin ?

  • Answered my own question after some hacking around.
  • If anybody finds problems with this, please let me know.
-- KeithHelfrich - 04 Jul 2006

When using the <editsections tag, is there any way to disable the automatic partitioning of a given heading within the topic. I ask because some sections obviously don't need to be edited, for example the table of contents %TOC and sections with a CommentPlugin box. It would be really nice to turn on sectional editing for a topic (or an entire web), but with the option to turn it off per section.

-- KeithHelfrich - 04 Jul 2006

An issue I found is the twist.js, part of the TwistyContrib. In the Dakar version of twiki, Edit links of SectionalEditPlugin on Firefox 1.5.0.4 do not jump to the editbox at first download, they jump to the #SECEDITBOX anchor only after the second download of the same page (weird). By commenting out twist.js, the anchor works fine, I don't know what is the problem and had no time to investigate it.

-- AndrasSzell - 05 Jul 2006

I have found a new problem, if anyone has a solution, please tell me: leading and trailing new line characters disappear around the editbox after a sectional save. Thank you.

-- AndrasSzell - 08 Jul 2006

I found those problems on Dakar only. Cairo is bugfree;). The worst behaviour is when <editsections/> tag is used. Then the trailing new lines are deleted. Other tags are safer, but still not perfect. When one section is edited the others should be rendered normaly. But sometimes headers of these sections are presented unrendered.

What I found so far, the empty line following <sectionbreak/> tag is deleted each time the sectional edit is used.

-- JacekZapotoczny - 13 Jul 2006

I've noticed this behaviour too. Thought that problem had been solved long ago.

-- FranzJosefSilli - 13 Jul 2006

Alan Pilch so kindly provided his system for testing. We have determined that this issue is due to again to the different way browsers treat multiline text passed via URL parameters. Per the spec there are no guarantees on that the browser will keep trailing or leading newlines.

We had a round of experiments during Cairo to figure out a solution working around this problem. Apparently in Dakar this problem crept back in.

We will have to once again study how different browsers handle the parameters passed in the Dakar style.

Time to dust of the old experiments....

-- ThomasWeigert - 19 Jul 2006

You did it once, you can do it again. wink Thanks Thomas!

-- FranzJosefSilli - 19 Jul 2006

Franz Josef, Jacek, and Andras, on the newline problem. I updated the EditContrib and on IE now once again get the identical text before and after edit (assuming no text was changed). As I have no other browsers installed, can you please install the new EditContrib and test on your browsers and advise. At least judging from the IE behavior this should have solved the problem you described with Dakar.

-- ThomasWeigert - 22 Jul 2006

I tested it on Mozilla Firefox (v1.5.0.4) and the tests were FAILED frown Still eats up the blank lines. I tested it also on IE and the tests were successful.

-- JacekZapotoczny - 25 Jul 2006

Jacek, could you please go to SomeBrowsersLoseInitialNewlineInTextArea and conduct the described experiment and then report back?

-- ThomasWeigert - 25 Jul 2006

According to my tests IE6 and Mozilla Firefox 1.5.0.4 both lose initial new line in textarea.

-- JacekZapotoczny - 27 Jul 2006

Jacek, I am somewhat at my wit's end... If the behavior of your browser in the text area is identical to IE, and IE behaves correctly, then there must be something else different.

It is difficult for me to debug without having your detailed example. Please send me your input text, describe your actions, and the result you obtain after edit. I will look further.

-- ThomasWeigert - 27 Jul 2006

Here's an interesting one (on CairoRelease): I've set EDITSECTIONS = TRUE in my Sandbox.WebPreferences. Having just received the first WebNotify email message from the sandbox web, contents of the webnotify email are "sectioned" around each topic that is included in the notification.

Choosing any of the edit section links takes you edit Sandbox.WebHome. Other point of interest that may be relevant : I'm using MailNotificationEnhanced (so I don't know if this behavior comes from an interaction between the two -- or if it is 100% SectionalEditPlugin ?)

-- KeithHelfrich - 30 Jul 2006

As I said in the docu, I am not sure whether it is a good idea to universally set EDITSECTIONS to true without adjusting various templates, that you would not want to be sectioned. I never use this feature for this reason.

-- ThomasWeigert - 30 Jul 2006

I must have missed that part in the docs, so now it is more clear (for myself and also for others). Looks like I was experimenting in the Sandbox for a reason smile Thanks.

-- KeithHelfrich - 31 Jul 2006

In order to further help debugging the browser specific issues raised above, I have installed a test system that you can access. Please go here, and log in as user TWikiGuest with password being the name of the home of the best wiki tool.

Please let me know if you find the errors there also. Please use the Sandbox web.

-- ThomasWeigert - 03 Aug 2006

OK. I broke down and installed Firefox. The explanation of the newline problem is at SomeBrowsersLoseMoreNewlines. I need to figure out how to protect the newline in the hidden URL parameters that are being passed.

I am amazed that this has not caused a problem otherwise yet....

-- ThomasWeigert - 03 Aug 2006

If I don't hear any better ideas, I'll work around this problem by prefixing the URL parameters passed with a character that does not get removed by the browser.

-- ThomasWeigert - 04 Aug 2006

Please download EditContrib for a new release the fixes the problem with Firefox 1.5.

-- ThomasWeigert - 06 Aug 2006

Thank you Thomas for your effort. Now, after EditContrib update all works just great;)

-- JacekZapotoczny - 07 Aug 2006 Is it correct that $sectiondepth defaults to 0 ? In my case, there were no "Edit" links visible at all until I changed $sectiondepth default to some other value. This was counter-intuitive for me, as older SectionalEditPlugin worked without any preferences.

-- AlexanderKrastelev - 11 Sep 2006

$sectiondepth is only needed when topics are sectioned automatically. This and the default value has not changed since earlier version.

-- ThomasWeigert - 11 Sep 2006

In Cairo release, when you chose edit for section, page was scrolled to textarea with section content. In Dakar when you choose edit for section e.g. at the bottom of a page you will see the top of it and have to scroll down to edit section. This is very inconvinient as after choosing "edit section" you have to look for textarea in the document.
I put it here as an error because this functionality was available in Cairo.

-- JacekZapotoczny - 21 Sep 2006

Thanks. Good point... Please download the latest version of EditContrib. The cursor will move to the text area upon edit.

-- ThomasWeigert - 22 Sep 2006

Auto-scrolling to edit window is really a good idea. However, in my case it behaves very strange:

  • In IE6, it works as expected
  • In Firefox 1.5 (both Windows and Linux) page doesn't scroll when I click on Edit section link (I see top of page). However, if (being already on editsection page) I put cursor into the URL line and just press Enter, it jumps to the edit box, as expected.
Any idea why it doesn't work from the first load in Firefox ?

-- AlexanderKrastelev - 22 Sep 2006

I think the no-jump-to-editsection behavior in Firefox is a byproduct/interaction of the pattern skin. I didn't notice this problem using the classic skin.

-- ScottHoge - 22 Sep 2006

I see we know more about the problem, but unfortunately last changes to EditContrib didn't fix it up. The cursor is not moved to textarea upon edit. I can only add that my tests confirm notes from Alexander and Scott and I'd like to stick to pattern skin;). As I'm Firefox oriented just like 36% of all users in my project (BTW 61% of them use IE) it's important that it works in both browsers.

-- JacekZapotoczny - 28 Sep 2006

Thanks for changing this default. Now I see the doco was correct wink

And a reminder ;-). Cursor is not moved to textarea upon edit.

-- JacekZapotoczny - 03 Oct 2006

Jacek, thanks for the suggestion. Did not know you could have more than 3 dashes in a header... Uploaded new version.

I believe the cursor move issue is a firefox issue as discussed earlier. I don't think there is anything that can be done.

In my installation (on IE) it moves the cursor to the textarea...

-- ThomasWeigert - 03 Oct 2006

Now sections are not presented in preview mode. Is there an easy way to show sections in this mode that preview is complete?

-- JacekZapotoczny - 04 Oct 2006

Don't understand your suggestion re "preview". We should not see sections in preview, right?

Jacek, thanks for the suggestion about another default. updated.

Your feedback and support is really appreciated. I know this is tedious, but it does help to make the plugin stronger...

-- ThomasWeigert - 04 Oct 2006

I only write down my problems, you are the One who solves most of them. Thanks for that Thomas wink

My suggestion about "preview". I think in this mode we SHOULD see sections because of at least two reasons:

  1. "preview" should reflect what will be seen on page while viewing it. In "view" mode we can see sections ;-),
  2. If sections are presented maybe we could set up anchors to each section.
The second point needs an explanation. I'm trying to make auto-scroling to edited section work for the plugin and for now it works quite well for me when saving document. I would like to check if it's possible to enable such functionality in "preview" mode as it also would be very comfortalbe while editing long documents. It's frustrating if you want to preview changes made in specific section, you press "Preview", and you see the top of the page and no even sections marked in text. So, even if anchors will not work in "preview" as expected, it will be very convenient to see where the sections are realy located. And the last but not least, if you edit the whole document and want to enable sections in it you cannot check if your changes are correct with "preview" because you simply wont see sections there. You are forced to save document to see if it's sectioned as expected.

Here are my changes enabling automate scroling to edited section after save. I also moved "Edit" link to inside section frame. When you have "Edit" between two neighbour sections you never know for 100% (if you don't use it each day;) if you are going to edit section above or below "Edit" link. Quasi solution for this (which I've used before) was setting LABEL to "Edit section above" or "Edit section below" (depends on PLACEMENT variable ;).

ALERT! Please, treat my changes as highly unsafe. Use at your own risk wink ALERT!

-- JacekZapotoczny - 05 Oct 2006

Jacek, I see where you are coming from. Just one comment on preview... Personally, I never use preview, and I don't think most people do. This is a vestige from the olden days when you had to go through preview to save. Now you can just as easy save and go back to edit, unless one is really worried that one's changes cause a mess.

All that said, I am not sure whether we really should section in preview. Let me stew over this one....

-- ThomasWeigert - 05 Oct 2006

Hmmm... personally wink I use preview and find it useful. The reason is that using preview is much faster than saving the changes and then going back to edit mode again. Note that using preview you avoid all IO file operations. The speed of our TWiki is a real problem.

-- JacekZapotoczny - 11 Oct 2006

i'll look at the preview...

-- ThomasWeigert - 11 Oct 2006

Great plugin! wink

Firefox problem:
I see that this was reported before. Firefox is not jumping to #SECEDITBOX for some reason. Could it be possible to implement a workaround for that? In fact with Firefox you still have to look up for your editbox in the same way you have to look up for the section you want to change when you edit the topic the standard way.

-- StephaneLenclud - 02 Nov 2006

Stephane, I do not know why Firefox is not able to handle the #SECEDITBOX jump. This all works as advertised in IE. Your second suggestion is already on the wishlist, so I moved your comment up.

-- ThomasWeigert - 11 Nov 2006

By looking into some HTML code lately I saw that people are using empty anchor tag with name property rather than having an id property in the div tag. That might be a workaround. I could try it out. Do you know the place in the code where I could output something just after the div id="SECEDITBOX". I guess I could just scan every files from EditContrib and SectionalEditPlugin for SECEDITBOX but that might be easier if you just tell me smile

I've added a comment above about that "jump to section upon saving" feature.

-- StephaneLenclud - 13 Nov 2006

Thanks for being willing to experiment. Please go to file templates/editsection.pattern.tmpl and make whatever change you think is good there. The current line 51 is

<div id="SECEDITBOX">

-- ThomasWeigert - 13 Nov 2006

I'm glad I asked because I would have been looking into the perl scripts smile Ok I tried a few things with the #SECEDITBOX and it just won't work with Firefox. In fact none of the #shortcut thing work upon loading that page with Firefox; I tried jumping the the bottom of the page for instance and even that won't work. I wonder if it could be due to some javascript we have on the edit page?

-- StephaneLenclud - 14 Nov 2006

Jumping to #patternBottomBar upon loading any edit topic just won't work with Firefox. So it's nothing specific to SectionalEditPlugin. I think we should open a bug for that. I'll see If I can get around doing it. Or maybe we should open a bug against Firefox, if everyone reading that is familiar with Firefox development process then please feel free to do so wink

-- StephaneLenclud - 14 Nov 2006

I recently "discovered" that TWiki now supports a tag %STARTSECTION% to denote sections for more precise inclusion. These tags could also be used for designating sections by SectionalEditPlugin and MultiEditPlugin. That way, users would have to learn less syntax, and the same syntax can be used both for section inclusion and section editing.

I am putting together a plugin that combines SectionalEditPlugin and MultiEditPlugin which leverages the new TWiki syntax. I am not planning to support the existing syntax in that plugin for performance reasons (different scanning mechanisms are required causing the topic to be scanned four times due to this plugin).

In the new plugin I am planning not to support the <sectionbreak /> feature, as it appears little used. I will continue to support editing sections identified by headings.

However, as a bonus I will support editing for sections included from other topics that actually works (you may not have noticed yet, but editing an included topic is not currently supported). In addition, every section identified by a headline will be includable in another topic.

-- ThomasWeigert - 14 Nov 2006

Sounds like a good plan Thomas!

-- PeterThoeny - 14 Nov 2006

Is this plugin supposed to work with 4.1? I can't seem to get it to work (downloaded through configure, checked file permissions, inserted the following in WebPreferences:

---++ Plugin settings

   * SectionalEditPlugin
      * Set EDITSECTIONS = 1
      * Set SECTIONDEPTH = all
      * Set SECTIONDEPTHMIN = 1

I'm using TemplateLogin, btw (no .htaccess)

-- JosMaccabiani - 26 Jan 2007

Sorry, as the plugin topic indicates, I have not been able to uprev it yet due to several superbusy weeks. Will attend to in Feb....

-- ThomasWeigert - 26 Jan 2007

We have it working in the office on 4.1. I don't ever remember changing any settings for it. We just enable it on per topic basis using <editsections/>. My only problem with it right now is that it's using a default template when NatSkin is enabled but I believe it's NatSkin issue.

-- StephaneLenclud - 28 Jan 2007

This is not working for me at all. I am on 4.05. I have changed the chmod on all the files to 755. I am trying it with just one document. I have tried all the different ways to make a section editable. Nothing happens. Does the .htaccess file have to be changed?

-- XochipalaValdez - 06 Feb 2007

Yes, of course.

-- ThomasWeigert - 07 Feb 2007

I have SectionalEditPlugin running on TWiki 4.0.5. It works fine (PatternSkin), expect when ExplicitNumberingPlugin is used. Description of the current operation:

  • Using editsections/> , the sections display correctly
  • When clicking "edit" from a section, an empty edit screen appears, without the section text.
It appears that SectionalEditPlugin ignores ---# -style tags used by ExplicitNumberingPlugin.

-- MikkoLaakso - 08 Apr 2007

I am using 4.1, and the plugin does not work (I am getting a blank page).

The problem seems to be that finalize_edit in EditContrib.pm expects a template parameter $tmpl: my ( $session, $pretxt, $sectxt, $postxt, $pretxtRender, $postxtRender, $tmpl ) = @_; This $tmpl-parameter is set to '' in the SectionalEditPlugin. This leads to a blank page. Any suggestions how to fix this? (i.e. what kind of template is reqested here?).

-- DortheLuebbert - 17 May 2007

aaah, forget the comment above. The rights for templates/editsection.pattern.tmpl were not correct.

-- DortheLuebbert - 17 May 2007

I'm using 4.1.2 and I've got a problem when editing a section and using the Checkpoint button. Clicking the Checkpoint button seems to construct a wrong URL (leading to a 404) which doesn't happen when clicking the Save button nor when using Checkpoint in "normal" editing mode (not sectional edit).

Using Checkpoint on a section of the page http://wiki/twiki/bin/view/Sandbox/SectionalEditTest leads to the following 404 error message:

The requested URL /twiki/bin/http://wiki/twiki/bin/editsection/Sandbox/SectionalEditTest/Sandbox/SectionalEditTest was not found on this server.

Has anyone else observed this behaviour or is it a problem of my setup?

-- MartinKaufmann - 06 Jun 2007

Another issue: When using the Pattern skin, the print preview still displays the edit tags for all sections although the Set SKIPSKIN = print,plain,viewprint is used. AFAIK, this is due to the print preview being defined by the CGI parameter "cover" and not "skin". I've attached a patch which includes a work-around.

-- MartinKaufmann - 07 Jun 2007

I have the same problem as MikkoLaakso wrt. ExplicitNumberingPlugin. I made it work by editing the regex in the editsection from
while ( $text =~ m/^---\+{1,$TWiki::Plugins::SectionalEditPlugin::sectiondepth}[^+]/mg ) {
to
while ( $text =~ m/^---[#+]{1,$TWiki::Plugins::SectionalEditPlugin::sectiondepth}[^#+]/mg ) {

-- JensMadsen - 19 Jun 2007

Has anyone had any luck using this plugin with MarkupEditorContrib? I have an issue where it won't even render the edit form and text area.

Using latest version of SeciontalEditPlugin. Any info is appreciated.

Update updating to correct EditContrib solved my problem.

-- EricHanson - 22 Jun 2007

is there any way or setting that a Sectional Edit can be able editable in a topic while keeping the topic locked?

-- TemesghenBzuayehu - 25 Jun 2007

I was wondering if anyone has shortened their urls and used SectionalEdit?

For the site, apache is setup so that / goes to bin, but the issue I have is that 'edit' links from sectional edit are "//sectionedit...". I currently have the Script Url set to '/', since it doesn't seem to like blanks.

Anyone found an easy solution to this? I noticed that sectional edit doesn't seem to generate fully qualified urls, rather relative.

-- EricHanson - 09 Jul 2007

Update

SectionalEditPlugin is using a deprecated method to get the path to the script directory; According to this document: http://twiki.org/cgi-bin/view/TWiki/TWikiFuncDotPm#get_ScriptUrlPath_path

Line 179 from:

my $eurl = TWiki::Func::getScriptUrlPath() . "/editsection/$web/$topic";   

to:

my $eurl = TWiki::Func::getScriptUrl() . "/editsection/$web/$topic";   

-- EricHanson - 03 Aug 2007

This is the first plugin which we've had real difficulty getting to work. Now that it is working, it is putting dotted borders around each of the sections on the page view. See example. I assume it is not meant to do this. Any tips on getting rid of this?

We are using TWiki 4.1.2 and SectionalEdit version 17 Aug 2006 and EditContrib 1.001

-- TamsinTweddell - 03 Sep 2007

What setting do you use for the plugin? If you leave the option Set STYLE set to its default value (i.e. style="border: black thin dotted"), it will of course show a black thin dotted line as a border around each section. Try class="twikiTopicActions" instead (or leave it empty).

-- MartinKaufmann - 03 Sep 2007

That's great. I overlooked the settings. Thanks for your help.

-- TamsinTweddell - 04 Sep 2007

The plugin instructs the following as a solution:


  • ALERT! I do not recommend turning sectional editing on globally, as this will also section topics that might not be desired to be presented in this form, e.g., email reports about web changes, various searches, etc. A much better approach is to put the <editsections/> tag into a custom template and apply it to a topic by setting the VIEW_TEMPLATE for topic, web, or site.

I would like to get same kind of editing as with MediaWiki. I have used couple of days trying to do according these instructions. I edited file view.pattern.tmpl by the following:

%TMPL:DEF{"textcontent"}%<div class="patternTopic">%TMPL:P{"broadcastmessage"}% %TEXT%</div><!-- /patternTopic-->%
TMPL:END%

-->

%TMPL:DEF{"textcontent"}%<div class="patternTopic">%TMPL:P{"broadcastmessage"}% <editsections/> %TEXT%</div><!-- /patternTopic-->%
TMPL:END%

I have also turned debug on and read code in SectionalEditPlugin.pm. The interesting thing which I found, is that if I change the template, I can see <editsections> in my web-page's source code, but cannot see it happen in log:

| 23 Nov 2007 - 08:26 | - TWiki::Plugins::::initPlugin( Sandbox.NoEditsectionsInPage ) is OK
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( NoEditsectionsInPage )
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( NoEditsectionsInPage )
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( NoEditsectionsInPage )
| 23 Nov 2007 - 08:26 | - TWiki::Plugins::::initPlugin( Sandbox.EditsectionsInPage ) is OK
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( EditsectionsInPage )
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( EditsectionsInPage )
| 23 Nov 2007 - 08:26 | - EditSections Found
| 23 Nov 2007 - 08:26 | - ::preRenderingHandler( EditsectionsInPage )

Page NoEditsectionsInPage is normal wiki page. Page EditsectionsInPage is similiar except having <editsections> included as first line of the page.

I'm asking for instructions how this is done in practice: ...put the <editsections/> tag into a custom template and apply it.... Thank you!

I'm using TWiki v4.1.2.

-- HeikkiArtola - 23 Nov 2007

A few comments:

  1. No updates for over a year. Please don't telll me this has been abandoned!

  1. The docs say, temptingly: A much better approach is to put the <editsections> tag into a custom template and apply it to a topic by setting the VIEW_TEMPLATE for topic, web, or site. My imagination fails me. Does anyone have an example?

  1. I want to implement Cornell Notes in TWiki. This means I want some side-by-side editable sections, probably using CSS. Has anyone done anything similar?
-- VickiBrown - 22 Dec 2007

I've got a first-draft of side-by-side editable sections (ala Cornell Notes) up at SectionalEditExample. It works. However, I think the page would be better implemented with a View template that did not include a "full page" edit link. (The underlying table code would be intimidating should anyone ever click the standard TWIki edit link.)

For this sort of multi-edit to work most efficiently, the user would probably want to move back and forth quickly between sections. We'd want anenhancement to SectionalEditPlugin the that would permit concurrent editing of different sections -- either the ability to open several sections simultaneously or, at minimum, a quick swap that would open another section for editing while saving the current -- but in any case without exiting the Edit screen (don't go back to View in between).

-- VickiBrown - 22 Dec 2007

Hi Vicki, I've implemented a completely new sectional edit plugin. See screenshots and specs at EditSectionPluginDev. SectionalEditPlugin is seriously broken, ie. does not work on 4.2 and needs patches to the core engine. No such thing is needed to get things like a sectional edit facility working again.

-- MichaelDaum - 23 Dec 2007

Is there an alternative to SectionalEditPlugin, as it is not compatible with TWiki 4.2? Can anybody help?

-- MartinSeibert - 25 Mar 2008

Martin, try EditChapterPlugin.

-- MichaelDaum - 30 Mar 2008

EditChapterPlugin not compatible with 4.2.3 too...

-- VictorKasatkin - 07 Oct 2008

And it does not support WYSIWYG either.

-- MartinCleaver - 07 Oct 2008

Thanks Thomas for updating the plugin! Does this plugin work on TWiki-5.0?

-- PeterThoeny - 2011-02-02

Thomas, there was a spurious Plugins.VarYELLOW, I removed it. It had this comment: "This topic is part of the documentation for SectionalEditPlugin and is automatically generated from Subversion. Do not edit it! Your edits will be lost the next time the topic is uploaded!". Could you exclude this topic from the build?

-- PeterThoeny - 2011-02-02

New AutoSectionsPlugin is available with similar functionality.

-- Peter Thoeny - 2013-05-06

Topic attachments
I Attachment History Action Size Date Who Comment
Perl source code filepm EditSectionPlugin.pm r1 manage 3.7 K 2005-08-31 - 14:24 RafaelAlvarez quick hack to edit a topic section in DEVELOP
Compressed Zip archivezip SectionalEditPlugin-AddonPopupPatchv1.zip r1 manage 6.2 K 2005-06-17 - 12:42 FredericLuddeni Patch addon popup v1.0
Unknown file formatpatch SectionalEditPlugin-Disable.patch r1 manage 0.8 K 2005-08-18 - 20:28 ChrisRiley Patch to disable sectional edit in a topic
Unknown file formatpatch SectionalEditPlugin-SkipSkin-Print.patch r2 r1 manage 0.6 K 2007-06-07 - 15:02 MartinKaufmann Patch to remove "Edit" tags in print preview using Pattern skin.
Unknown file formattmpl editsection.koala.tmpl r1 manage 5.5 K 2006-07-04 - 04:42 KeithHelfrich editsection template for KoalaSkin (tested on CairoRelease)
Unknown file formatJPG sectinal_edit_screenshot.JPG r1 manage 149.6 K 2007-09-03 - 12:31 TamsinTweddell Example of problem with dotted borders
Edit | Attach | Watch | Print version | History: r330 < r329 < r328 < r327 < r326 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r330 - 2013-05-06 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.