Question

I have a cron job that uses PublishContrib to publish our TWiki webs to static HTML pages. I've also made the PublishContrib topic available on each web, so that users can publish their changes. However, I've just gotten a complaint from a user that wants a "Publish" button on each and every topic page, or a checkbox on the Edit page, so that they have the option of publishing every time they make a change.

I don't personally agree with this request, but I have to do due course in exploring it... so I ask whether this is possible, and if so, how it can be implemented? Also open to your suggestions and ideas for dealing with such requests.

Thanks, ~John

Environment

-- JohnDeStefano - 07 Nov 2006

Answer

It depends on a) the skin you use and b) where the button should be placed: top, bottom or both.

-- ArthurClemens - 07 Nov 2006

In PublishWebPlugin, I put a link into the WebLeftBar to re-publish the topic. (Although the PublishWebPlugin publishes the topic on every topic save, sometimes it is useful to re-publish a topic (dynamic content; skin change...)).

-- PeterThoeny - 08 Nov 2006

In the TWiki, I'm using PatternSkin; for publishing, I created a PatternSkin variant.

Adding a "Publish" button to both the top and bottom might be best. How would one do this? Also, is it possible to instead add a publishing option to the editing page?

I'm also not entirely clear on the relationship between PublishContrib and PublishWeb (except that one calls itself "the original publishing extension") and whether they can (and do) work together.

-- JohnDeStefano - 08 Nov 2006

To customize the PatternSkin, the toolbar on top is defined at viewtoolbar.pattern.tmpl, the action buttons at the bottom at viewtopicactionbuttons.pattern.tmpl.

The PublishWebPlugin is designed for ease of maintenance of a website in TWiki (automatic html update on topic save, lowercase letters in generated URL, lightweight and fast, etc.); the PublishContrib is a generic publishing tool for different purposes and output formats.

• PublishContrib includes managed website publishing -- SD

-- PeterThoeny - 08 Nov 2006

Thanks... what is the class/template code needed to include a Publish button in either toolbar? I see the existing definitions (edit, WYSIWYG, search, print), but I'm not able to determine what code would be needed to add a "Publish" function.

I apologize if this is assumed knowledge or documented somewhere; if so, I'd be grateful for your direction.

-- JohnDeStefano - 09 Nov 2006

Did you figured it out?

-- MiloValenzuela - 17 Nov 2006

Nope.

-- JohnDeStefano - 17 Nov 2006

Peter, what code is needed to trigger a 'publish' event?

-- ArthurClemens - 17 Nov 2006

I am not familiar with PublishContrib, I guess it is a simple URL.

-- PeterThoeny - 17 Nov 2006

How would you do it with PublishWebPlugin? I've got that installed as well.

• With the PublishWebPlugin you do not have that problem, it is designed for ease of use, e.g. every time you save a topic, the static html page is generated again. If needed you can add a link to the sidebar or a button to the toolbar to re-publish the topic without a edit/save cycle using this link: [[%SCRIPTURL{view}%/%WEB%/WebPublish?action=publish;ptopic=%BASETOPIC%][Re-publish this topic]] (the WebPublish topic is included in the plugin package.) -- PeterThoeny - 22 Nov 2006

To be quite honest, the need for such a solution has become somewhat desperate on my end, as users have begun clamoring for the feature and have threatened to move their collaboration to some other platform if it can't be provided immediately.

-- JohnDeStefano - 21 Nov 2006

If I understand well, you need a publish button on every page to publish a web, is that correct?

-- ArthurClemens - 21 Nov 2006

Forgive me if any of this is overkill or unnecessary, as I'm unsure whether you're asking me for clarification, and I want to be as helpful as possible.

Currently, I have set up cron jobs that run the PublishContrib script ("publish") twice per day. I specify each web in a separate "publish" command, followed by any topics to be excluded, and the "skin" parameter, which specifies the name of the skin to be used when publishing; in my case, I've copied the pattern skin files to another set of files ("anon"), in which I've made minor customizations. And finally, in bin/LocalSite.cfg, a {PublishContrib}{Dir} directive specifies a general location for publishing.

Since users would be editing one topic page at a time, and since the entire webs are published automatically at specified intervals, these specifications would seem to make the most sense in my particular case (and perhaps those of others):

In the customized skin, which is used to publish the TWiki site to static HTML, the top bar should contain only an "Edit" button, which would point to the URL of the associated topic on the actual TWiki (currently, I've hidden the entire top bar in the published HTML). This would allow users viewing the static content to edit pages on the live TWiki site almost seamlessly: they'd only need to click the Edit button, which would redirect them to the proper page on the protected TWiki, which prompts them for a Kerberos login.

Then, in the TWiki itself, the "edit" script could include an option to publish the content on save. Thus, as users edit and are about to save their changes, they could simply toggle a check box in order to have their content published to the static site automatically. This would publish only the particular topic being edited.

Again, sorry if that's too much information.

Maybe a button like this in the TWiki topic top bar:

<span class="patternButton"><a href="/twiki/bin/publish?cover=anon" 
title="Publish this topic for unauthenticated users">Publish</a></span> 

(of course, this would not provide anything new on the edit page, but at least it would enable users to publish their newly-edited topic immediately after editing and saving.)

And maybe a button like this in the publishing skin:

<span class="patternButton"><a href="https://<authenticated_site_URL>/%WEB%/%TOPIC%" 
title='Edit this topic text'>Edit</a></span>

-- JohnDeStefano - 21 Nov 2006

I wouldn't know how to use a checkbox to publish on saving - not to say it can't be done, but I don't have any experience using this contrib.

When you create the 'publish' button it seems that you need to send a couple of publish settings along. I think you need to:

• copy the form on the PublishContrib page
• insert your default values
  • put the current topic as %BASETOPIC% in the =inclusions field
• hide the input fields with type="hidden"
• use the Publish button as form submit button

To add this button to a template, please read PatternSkinCustomization if you haven't already. In your view.anon.tmpl (since anon is the name of your customization skin) write:

%TMPL:DEF{"publishbutton"}%<form><input type="submit" class="twikiSubmit" value="Publish" /></form>%TMPL:END%

With the rest of the form fields the inside the form.

Depending on where the button fits best insert it in a proper place in the template. One suggestion is just below the topic contents. Also in view.anon.tmpl:

%TMPL:DEF{"aftertext"}%<div class="twikiAfterText" style="margin:0 0 1em 0;">%TMPL:P{"publishbutton"}%</div>%TMPL:END%

I hope this helps you along.

-- ArthurClemens - 21 Nov 2006

I've just updated the PublishContrib doc page as well as the PublishWeb page.

-- ArthurClemens - 21 Nov 2006

Thank you Arthur. In my case, these button templates would need to be added to the pattern skin template files, as I'm only using my custom ("anon") skin to transform the TWiki to an HTML "mirror" via publishing. The TWiki site itself is still using the stock pattern skin. Do you see any issue in adding these to that skin... ? would it break anything?

• First read PatternSkinCustomization - How to modify Pattern Skin templates for info on overriding pattern skin page elements. Then use the above code for view.anon.tmpl in your "team" (?) skin. So that would become your new view.team.tmpl. -- ArthurClemens - 21 Nov 2006

Also, to where would you copy the PublishContrib form? To a new page within each web, or within an actual template?

• Put it in your view.team.tmpl, because you would need it to be on every page. -- ArthurClemens - 21 Nov 2006

As for the other piece of the puzzle: adding an edit button to the published pages that links back cleanly to the appropriate TWiki topic. One of the reasons that I removed the top bar and bottom topic functions from the published pages was that one of the Edit buttons (top or bottom; I can't remember which now) linked back properly to the TWiki, while the other led to a broken URL. Would you happen to be familiar with such an error? Would the syntax in my previous post work?

• I think you need to link to the (view) page using either [[%TOPIC%][Edit]] or [[%SCRIPTURL{view}%/%WEB%/%TOPIC%][Edit]]. To actually link to the edit page, use [[%SCRIPTURL{edit}%/%WEB%/%TOPIC%][Edit]]. -- ArthurClemens - 21 Nov 2006

-- JohnDeStefano - 21 Nov 2006

OK. I've gotten most of the way there, but I'd appreciate your feedback and suggestions for improvement.

In the new file view.team.tmpl (where "team" is the customized version of pattern to be used for displaying TWiki pages:

%TMPL:INCLUDE{"view.pattern"}%
%TMPL:DEF{"publishbutton"}%
<form method="POST" name="publish" action="%SCRIPTURL{publish}%">
<input type="hidden" name="web" value="%WEB%" />
<input type="hidden" name="inclusions" value="%TOPIC%" />
<input type="hidden" name="skin" value="anon" />
<input type="hidden" name="format" value="file" />
<input type="submit" class="twikiSubmit" value="Publish" title="Publish this topic for unauthenticated users" />
</form>
%TMPL:END%
%TMPL:DEF{"aftertext"}%<div class="twikiAfterText" style="margin:0 0 1em 0;">%TMPL:P{"publishbutton"}%</div>%TMPL:END%

The result: a new "Publish" button appears after the text on each page, and clicking it publishes the topic just fine. I'd like to be able to surpress the red "not included" messages from user feedback, as I'm sure that will be a complaint later. It also returns 12 instances of the following error for the page being published:

failed to GET <Our_TWiki_URL>/twiki/pub/TWiki/TWikiDocGraphics/web-bg.gif

Other than that, it seems to work just fine.

In the existing file view.anon.tmpl (where "anon" is the skin used for publishing the TWiki content), the top toolbar and bottom buttons had been completely hidden. I changed the toolbar entry as follows:

%TMPL:DEF{"toolbar"}%<span class="patternButton">[[https://<Our_TWiki_URL>/twiki/bin/edit/%WEB%/%TOPIC%][Edit this page]]</span>%TMPL:END%

I had to include the actual URL, as it's not in the same server space and uses HTTPS.

The result: an edit link shows up at the top, but not as a button (shouldn't class="patternButton" handle that?), and not right-aligned (I tried including

style="text-align:right;"

with no luck).

One problem so far, which may be a problem with the publish script itself and not necessarily the Publish button: I found that using this method to publish a page that contains many graphics (in particular, graphics being pulled in from other sites) fails with apache timeout errors on my server:

[Wed Nov 22 12:32:02 2006] [error] [client 130.199.54.3] (70007)The timeout specified has expired:
ap_content_length_filter: apr_bucket_read() failed, referer: https://<site_URL>/twiki/bin/view/<web>/<topic>

The action shows up in the TWiki logs only as a "view" action. The dynamic TWiki page that reports script activity stalls in the middle of the script.

-- JohnDeStefano - 22 Nov 2006

Use toolbar_buttons to place your button. Like this:

%TMPL:DEF{toolbar_buttons}%<div class="patternToolBarButtons"><span class="patternButton">[[https://twiki/bin/edit/%WEB%/%TOPIC%][Edit this page]]</span> and the other buttons here
</div>%TMPL:END%

Within TWiki context always add a unique number to prevent that people are editing older versions. Like this:

<a href="http://path/to/your/edit/topic?t=%GMTIME{"$epoch"}%

not sure how you would do that outside of TWiki. Perhaps just publish the unique button edit number along with the topic.

On web-bg.gif, check if the file is there, if permissions are correct.

The timeout issue: wouldn't that be a web server setting? Otherwise create a new Support entry.

-- ArthurClemens - 22 Nov 2006

On timeout, possibly post on PublishContribDev to improve the performance of the publishing process. For comparison, PublishWebPlugin does a "publish all content" of the structuredwikis.com website in 2 seconds (it includes many images and a few GB ppt files.)

-- PeterThoeny - 22 Nov 2006

The toolbar button works great. Thank you. I'm not sure how to handle the versioning/editing issue in the non-TWiki link.

On the "missing" web-bg.gif graphic: the TWiki is in /var/www/twiki, and the graphic exists at: /var/www/twiki/pub/TWiki/TWikiDocGraphics/web-bg.gif

That seems to match the location reported by:

failed to GET <Our_TWiki_URL>/twiki/pub/TWiki/TWikiDocGraphics/web-bg.gif

I've added the publish timeout stuff to the PublishContribDev page. The response there was "buy a faster server".

It sounds like PublishWeb might be something to consider, especially if it publishes a bit faster and can be enabled to "publish on save" whenever someone edits a topic. Again, I apologize for my ignorance of any differences between the two mechanisms, historical or political. In my situation, since we're using rewrite rules to mirror the authenticated TWiki and unauthenticated content, the lower-case name conversion might be an issue.

Finally, and I'm not sure why: now that I've added the "Edit" link (which goes directly to the TWiki edit script on the public pages), the public pages are prompting for a local user/pass.

-- JohnDeStefano - 22 Nov 2006

Folks, the issue in last paragraph above is a big one: users looking at the pure HTML, unauthenticated pages should not be prompted for a login/password just to view them. I've found that the login is necessary in order for the background color swatches for each Web in the left bar to appear. This happens only on pages that have been published using the Publish button mechanism we've discussed here. I'm not sure why that's happening, as the URL handed to the Publish script is not hard-coded:

<form method="POST" name="publish" action="%SCRIPTURL{publish}%">

My guess is that the errors on graphics reported during publish (also mentioned above) are related to this issue.

-- JohnDeStefano - 27 Nov 2006

What HTML code is generated for these icons, what file references? Then could you check the file permissions of these files?

-- ArthurClemens - 27 Nov 2006

Here's an example of one of the left menu list items, and the link to the authenticated image source it's looking for:

<li> <a href="/twiki/bin/view/TWiki/WebHome"><img src="https://[our_URL]/twiki/pub/TWiki/TWikiDocGraphics/web-bg.gif" border="0" alt="" width="16" height="16" style="background-color:#FFD8AA" />&nbsp;TWiki</a></li>

I believe that the file is owned properly by apache:

# ll /var/www/twiki/pub/TWiki/TWikiDocGraphics/web*
-rw-rw----  1 apache apache 85 Oct 17 09:55 /var/www/twiki/pub/TWiki/TWikiDocGraphics/web-bg.gif
-rw-rw----  1 apache apache 77 Oct 17 09:55 /var/www/twiki/pub/TWiki/TWikiDocGraphics/web-bg-small.gif

-- JohnDeStefano - 27 Nov 2006

Try to chmod that to -rw-rw-r--.

-- ArthurClemens - 27 Nov 2006

I noticed that all the other image files in that directory had the same 660 permissions (-rw-rw----) and ownership (apache:apache).

Anyway, I tried changing them to 664, but no luck. I then ran the publish script from the command line again on that page, and the errors (as well as the login prompt) went away. So there seems to be some difference in the way the Publish "button" works in juxtaposition with calling the publish script manually.

I also tried giving apache a login shell (apache is the user running the web server and the owner of the TWiki files; the account doesn't have a shell by default for security reasons), but that didn't seem to make a difference when using the Publish button.

-- JohnDeStefano - 27 Nov 2006

Maybe one possible solution lies in further automation: what would it take to "hack" the edit script so that the topic that's being edited is also published on save?

Could it be as simple as customizing edit (just the script; not the module) by adding these lines from publish, or would this break something:

use TWiki::Contrib::Publish;
TWiki::UI::run( \&TWiki::Contrib::Publish::publish );

I tried that myself, and it didn't seem to break anything, but it also didn't publish anything on save.

-- JohnDeStefano - 28 Nov 2006

It's been a week since anyone's responded here. I'll try opening a new topic specific to my last question.

-- JohnDeStefano - 04 Dec 2006

The question has gotten muddled in the thread. Could you give a short summary again?

-- ArthurClemens - 04 Dec 2006

Sure: I have a TWiki site that is authenticated via HTTPS and local credentials, and I'm using the "publish" script to transform the site to unauthenticated HTML via a cron job. The site users would like to be able to publish their changes themselves, but instead of going to the PublishContib topic, they want a more automated publishing mechanism.

This thread has gotten me to the point of adding a "Publish" button to the top tool bar of each page. The first problem is that although the publishing action triggered by the button completes "successfully" (excepting the feedback shown above), the pages published by clicking the button are hard-coding links to authenticated (HTTPS) images on each page, and thus are asking users for a login/pass on each page in order to display the images. Pages published via the publish script from the command line do not produce this issue.

Second, to alleviate all this, I was hoping to somehow combine "edit" and "publish" so that clicking "Save" during an edit session would automatically publish the saved topic. I've not been able to do so.

-- JohnDeStefano - 05 Dec 2006

No activity over 30 days, I am closing this.

-- PeterThoeny - 01 Feb 2007

That's a shame. I'm still waiting for an answer. Thanks anyway.

-- JohnDeStefano - 02 Feb 2007

-- JohnDeStefano - 03 Feb 2007

Change status to: AskedQuestions AssignedQuestions AnsweredQuestions ClosedUnanswered