Tags:
create new tag
, view all tags

PublishContribDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on PublishContrib 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 file bug reports in the PublishContrib bug database.
• See PublishContribDevArchive for older discussions.
• RENAMED FROM PublishAddOn
• This is the original web publishing tool. Use the PublishWebPlugin to maintain your website collaboratively in TWiki.

Discussion on PublishContrib

Contents:

-- CrawfordCurrie - 27 Feb 2006

WIBNIF (wouldn't it be nice if....)

  1. There was a a PDF option, that ran the output through htmldoc (if it is available on the server) to generate a PDF instead of a ZIP -- CrawfordCurrie - 27 Apr 2005
    • There is now
  2. There was a tar.gz option as well as zip -- CrawfordCurrie - 27 Apr 2005
    • There is now
  3. You could delete previously generated zips from the browser -- CrawfordCurrie - 27 Apr 2005
  4. You could choose a name for the generated zip -- CrawfordCurrie - 27 Apr 2005
  5. You could ask for the publish process to be run in the background get a mail with the zip attached when it's finished. -- CrawfordCurrie - 27 Apr 2005
  6. The publish process would run with the HTTP AUTH credentials of the user who's doing the publishing, instead of TWikiGuest, so you could publish restricted-access webs/topics -- EricSorenson - 21 Sep 2005. -- RasmusOryNielsen - 12 Dec 2005
  7. The Attachement on the page for the Cairo version had the Cairo code, not the Dakar version. -- EricHanson - 05 May 2006
  8. The "publish to" directory was configurable, rather than being tied to the web variable. Eg: you're in the Publish web, so SomeTopic (currently) gets published to url/Publish/SomeTopic.html, but you want to publish one/any/all pages to url/Newdir/SomeTopic.html (using the file output option). -- MarcusLeonard - 21 Dec 2006
  9. You could delete published files (using the file output option). -- MarcusLeonard - 21 Dec 2006

Discussions

When using PublishContrib with ImageGalleryPlugin:

The small images are exported correctly, but the links are not:

  • the `dot'-link still points at the dynamic version (could be handy to have it export the full image instead)
  • the image-link points at a strange place: (relative to my EXPORTED directory) EXPORTED/Main/rsrc/format=file/WebHome/_igp1/thumb_dsc00183.jpg
creating this directory makes the export process work, however the image-link really points at: EXPORTED//format%3dfile/WebHome.html?id=1&filename=dsc00183.jpg#igp1

any idea ?

thank you otherwise for your excellent work!

(see also PublishContribAndImageGallery)

-- MarcSCHAEFER - 14 Aug 2006

  • It would be nice to have some way of control how the exported data is named. A file listing equivalents in the TWiki could be used by the export process. If I have some time I will try to create patches for this idea. But the idea is to not have for example NF.html and NFContact.html, but index.html and contact.html, with a list of TWiki names and external file name.
  • 2006-09-14: first implementation, breaks ImageGalleryPlugin (but see above anyway)
-- MarcSCHAEFER - 29 Aug 2006

Publish does not play nice with WorkflowPlugin. %WORKFLOWSTATEMESSAGE% always expands to the waiting for revision state when publishing with the text skin. When using the plain or print skins, I see %WORKFLOWSTATEMESSAGE% verbatim.

Also, I noticed that when saving to .zip the TWiki logo image at the bottom of the page does not load, but it works for .tgz.

-- ChrisPurves - 22 Sep 2006

Marc, I'm sorry, but I couldn't make any sense of your patch. You didn't patch the documentation, or provide any other explanation of what you were trying to do, so I'm afraid I have to reject the patch.

Added Guillaume's patch in

Chris, I'm sure WorkflowPlugin isn't the only plugin that doesn't play nicely with publishing. Most plugin authors assume you are always viewing. Drive back onto the author of WorkflowPlugin, and get them to honour the "publishing" context identifier.

-- CrawfordCurrie - 23 Sep 2006

Crawford, what does it mean to "honour the publishing context identifier"? I assume that is to state that one enters the publishing context. But how many context can you be in? Also, how do we ensure that people are in general honouring these contexts? Shouldn't this be in the control (somehow) of the publisher of the PublishContrib? E.g., there could be a default twiki context stack everybody could push on (or maybe one specific for each of the key scripts), and plugins could pop off things they don't handle, but otherwise all those contexts would be active?

One cannot expect from a plugin writer to study all other plugins to see what they need in terms of context?

-- ThomasWeigert - 26 Sep 2006

The command line interface for the script makes it simple to publish multiple Webs within a TWiki installation simultaneously (well, as quickly as a script can execute linear publish requests). However, in order to get links between Webs to work properly, one has to do some tricky redirection to the parent folder of all Webs. Is there any way that all Webs within a TWiki could be published at once to a parent folder, which could be used to link to the "Main" Web's WebHome directly?

-- JohnDeStefano - 23 Oct 2006

Also wondering what template files are required in order to allow publishing with customized templates? I have customized a single template file (view.myskin.tmpl) that inherits the properties of the patternskin templates, with some customized stuff. When I preview pages with this custom template, the pages appear just as expected. But when I pass this template as a "skin" to a publish command line, the results are blank pages with only empty paragraph tags.

-- JohnDeStefano - 24 Oct 2006

Publishing 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>

When I publish manually using the perl script, the script stalls at this page and eventually reports "failed to GET" errors for remote, PHP-generated images, and "LWP not installed - cannot fetch" errors for remote PNG files (am I missing a module?).

When I publish from within TWiki, the dynamic TWiki page that reports script activity stalls in the middle of the script, and the publish action shows up in the TWiki logs only as a "view" action.

-- JohnDeStefano - 22 Nov 2006

Jens, no idea what that was, I just downloaded using the link you gave above and got the Cairo version OK.

John, does "buy a faster server" strike a chord with you? One thing someone might thing of doing is to add a map of URL paths to physical disc locations, to avoid the roundtrip when grabbing NFS-accessible files.

Marc, the reason I'm not going to apply your patch is ... no documentation.

-- CrawfordCurrie - 23 Nov 2006

John, does "buy a faster server" strike a chord with you?

Sure: I'd always love to upgrade any equipment I'm running; however, that's not always feasible. Our TWiki is running on a dedicated machine, and while it's not stat-of-the-art bought-tomorrow hardware, it's not junk yet. If the module has a minimum or recommended hardware requirement, please let me know. All I found regarding hardware reqs anywhere in TWiki's specs was that "Low client and server base requirements are core features that keep TWiki widely deployable".

If you think mapping URL paths to locations would help alleviate the error I posted, please let me know how, or give an example?

-- JohnDeStefano - 30 Nov 2006

Sarcasm aside, the reason I said "buy a faster server" was nothing to do with the contribs requirements. It's to do with your server's ability to serve all those requests for graphics pages (which may be affected by the contrib running, but is more likely to do with your apache configuration). If the graphics are coming from a completely different site, tell them to buy a faster server wink

Frankly, I'm rather confused as to what is happening here. You say that this occurs when rendering a page full of graphics "from other sites". For the contrib to stall, it has to be hanging in a module it calls; most likely LWP, which is used to issue HTTP requests to other sites. IIRC if LWP is not installed, it won't even attempt to get pages from other sites. AFAIK LWP doesn't use any part of apache, so it can't fail in ap_content_length_filter (which is a function in apache). Further, if a remote site can't serve something, it responds with an HTTP status code, which LWP would handle gracefully. If LWP were timing out on the request, I would again expect a graceful recovery, as the code is designed for this eventuality.

Another possibility is that the timeout is actually happening on a request for a graphic hosted on your server. In that case, I would expect LWP to recover gracefully from the timeout, even if there was an error.

A third possibility is that the error is raised when another apache module is processing the output from the contrib before sending it to the browser. this depends on your apache configuration, what modules you have installed etc.

Without a lot more analysis of what is actually happening, it is hard to give any more constructive advice. However there are some obvious sanity checks;

  1. Make sure LWP is installed and is at the latest version
  2. Check the other dependencies of the contrib at the same time
  3. Check what other apache modules are installed
  4. Search google for the error messages, and see if the hits provide any clues
-- CrawfordCurrie - 01 Dec 2006

I have an internalization problem; none of the umlauts (ä,ö,é,etc) get rendered correctly with PublishContrib. Instead I get a box with a questionmark on Xubuntu, and a plain box on windows. I tried to mess with the internalization settings on config, as the documentation suggests here, but no effect. Any idea about what's going on here?

-- MikkoLaakso - 11 Dec 2006

It seems this is a problem in Apache, the umlauts render fine when opening the static file straight from hard disk! Does anybody know how to fix this?

Edit: Solution was to uncomment the line "AddDefaultCharset ISO-8859-1" from apache conf.

-- MikkoLaakso - 11 Dec 2006

Or, you could do: AddDefaultCharset Off

But as you've said, this is an apache setting and has little to do with publish or even TWiki.

-- JohnDeStefano - 12 Dec 2006

Publish Blog Web Issue

Hi, i use PublishContrib, and it works well in wiki web, but when i want to publish a Blog web, it can only publish pictures in blog web page, without any text. Is this caused by my installation or PublishContrib. How can i fix that? Thanks smile

-- ShashaLuan - 26 Dec 2006

%BASETOPIC%

doesn't seem to be expanded correctly while publishing. As I use this variable to modify the LeftBar content (context-specific), it breaks.

%TOPIC%

is correctly expanded, but unfortunately, in an INCLUDed topic it is not the right value from the start.

-- MarcSCHAEFER - 27 Jan 2007

I think I have fixed the %BASETOPIC% bug in an earlier TWiki release. The current release doesn't seem to have the bug anymore.

--- Publish.pm-2007-04-25       2007-04-25 14:40:06.000000000 +0200
+++ Publish.pm  2007-04-25 16:28:08.000000000 +0200
@@ -404,6 +404,11 @@
 
     # SMELL: need a new prefs object for each topic
     my $twiki = $TWiki::Plugins::SESSION;
+
+    # Make sure %BASETOPIC% works
+    # schaefer 2007-04-25
+    $twiki->{SESSION_TAGS}->{BASETOPIC} = $topic;
+
     $twiki->{prefs} = new TWiki::Prefs($twiki);
     $twiki->{prefs}->pushGlobalPreferences();
     $twiki->{prefs}->pushPreferences($TWiki::cfg{UsersWebName}, $wikiName, 'USER '.$wikiName);

-- MarcSCHAEFER - 25 Apr 2007

Sorry for taking so long to get around to fixing this extension, but the need to make a living keeps getting in the way. A new version will be uploaded today. If at any point you need a fix urgently, please feel free to contact me directly for contract rates.

I have cleaned up the threads above to reflect the fact that most of the reported problems have been solved.

I have not incorporated marc's name equivalence patch, however. I remain to be convinced that is is useful enough to avoid the inevitable confusion it will cause to beginners.

I have also not tested with ImageGalleryPlugin. if someone could do that, and report any problems as Bugs, then there's a chance they'll be fixed smile

CC

Thanks Crawford.

I upgraded the extension to the new version (Nov. 10), but publish exited with an error before publishing anything: Too late for "-T" option at publish line 1.

It seems that running publish as a stand-alone script instead of with perl ( ./publish web...) gets it to run again, but with the same raw HTML output and the same errors as I had seen before:

  • publish: Use of uninitialized value in print at /var/www/twiki/lib/TWiki/Contrib/Publish.pm line 389.

  • Use of uninitialized value in scalar assignment at LocalLib.cfg line 30.

  • Use of uninitialized value in transliteration (tr///) at LocalLib.cfg line 33.
Changing the original perl command from perl publish to perl -T publish seems to do the same thing, with the same errors and raw output.

Publishing the TWiki web with these commands introduces a slew of "uninitialized value" errors, all of which have to do with Time.pm and FileListPlugin.pm.

-- JohnDeStefano - 29 Nov 2007

The LocalLib.cfg errors are yours; that's nothing to do with PublishContrib. The other error is a bit of sloppy coding on my part, but it should be non-fatal.

-- CrawfordCurrie - 07 Dec 2007

Crawford, could you please elaborate: "The LocalLib? .cfg errors are yours; that's nothing to do with PublishContrib."

I see these errors only in the context of using publish. If there's something obvious I should be doing to alleviate the errors, please let me know?

-- JohnDeStefano - 22 Jan 2008

When running this on one topic I get the following error.

ERROR: WebHome not published: Illegal format for login name 'PeterJones' (does not match ^.+@[^\.].*\.[a-z]{2,}$) at /usr/lib/perl5/5.8.5/CGI/Carp.pm line 314. at /usr/lib/perl5/5.8.5/CGI/Carp.pm line 314 CGI::Carp::realdie('Illegal format for login name \'PeterJones\' (does not match ...') called at /usr/lib/perl5/5.8.5/CGI/Carp.pm line 385 CGI::Carp::die('Illegal format for login name \'PeterJones\' (does not match ...') called at /afs/cern.ch/project/twiki/beta/4.1.2/lib/TWiki.pm line 1384 TWiki::new('TWiki', 'PeterJones', 'CGI=HASH(0x8709e3c)') called at /afs/cern.ch/project/twiki/beta/4.1.2/lib/TWiki/Contrib/Publish.pm line 524 TWiki::Contrib::Publish::publishTopic('TWiki::Contrib::Publish=HASH(0x9512d7c)', 'WebHome', '.html', '%TEXT%\x{a}---\x{a}%META{"form}%\x{a}---\x{a}%META{"attachments"}%\x{a}', 'HASH(0x8eaacb4)') called at

We have SSO and Shiboleth authentication and in the lib/Localsite.cfg we have an entry

$TWiki::cfg{LoginNameFilterIn} = '^.+@[^\\.].*\\.[a-z]{2,}$';

Following the error all access to Twiki is broken for this session. I have to log off to be able to use TWiki again as any futher attempts to use Twiki give

Software error:

Illegal format for login name 'PeterJones' (does not match ^.+@[^\.].*\.[a-z]{2,}$) at...

-- PeterJones - 19 Feb 2008

I see this is 4.1.2, and the username you have given is "PeterJones". The error is thrown in the guts of TWiki, and occurs because the string "PeterJones" does not match the setting of {LoginNameFilterIn} in configure (judging from the error message, this is expected to be an e-mail address)

-- CrawfordCurrie - 21 Feb 2008

This contrib does not render view templates. I found a workaround. If you have a view template called PageViewTemplate in Main Web,

  • Create a template file templates/view.page.tmpl
  • Write in that file: %TMPL:INCLUDE{"Main.PageViewTemplate"}%
  • Add page to the list of publishskins, for instance: page,pattern
-- ArthurClemens - 24 Feb 2008

Thanks for the heads-up Arthur. Did you add a bug report?

-- CrawfordCurrie - 27 Feb 2008

I published a web using the zip and the file output formats and it seems that the topic attachments aren't published alongside the topic's contents. I mean I would like that the attachments table that is shown in the footer of the topics be published so that I could have access to all the attachments in the published version.

Is this really a missing feature or am I missing something else?

-- GustavoChaves - 14 Mar 2008

I have the same problem when I tried to published a web using the html format. I would like that the attachments table that is shown in the footer of the topics be published so that I could have access to all the attachments in the published version.

-- CarlaRego - 07 Apr 2008

I too have this issue with attachments not being published, though I'm not sure whether it's a problem with the software, or an intended consequence.

You might take a look at FileListPlugin, but this requires modification of your skins.

-- JohnDeStefano - 08 Apr 2008

-- PeterJones - 19 Aug 2008

With reference to my question on 19-feb

The setting {LoginNameFilterIn} does indeed match an email address.

From other posts its would appear that this is a common setting. We have a user list in the form.

  • WikiName - emailaddress - date
The error seems to state that my WikiName does not match an email address, which is true. I don't want to change the user list and the {LoginNameFilterIn} is corretly set, so how can I get around the error that is thrown?

-- PeterJones - 19 Aug 2008

Publish crashing with no error.

Hi, I have a single web with 3 or four pages and 18gb of attachments on WebHome. I only get about 5gb published before the script crashes - any ideas to work out whats happening?

Terry Rankine

-- TerryRankine - 20 Aug 2008

The problems with attachments are most likely a result of using a publishing skin that does not include the attachments. Attachments will be published alongside the topics, but only if they are referred to from within the topics.

Peter, the contrib doesn't use LoginNameFilterIn, so that error is coming from somewhere in the core. Can you determine where?

Terry, my crystal ball has crashed. How about you tell us what the error message is?

-- CrawfordCurrie - 20 Aug 2008

Peter, I just tried to reproduce the problem you reported. However I can't find the string "Illegal format for login name" anywhere in TWiki, so I'm guessing that it is being generated by a plugin or another contrib.

-- CrawfordCurrie - 20 Aug 2008

Hi Crawford,

It crashes part way through the attachment copy with no errors on the terminal ( perl -T publish web=Cobar format=file) Is there a way of putting the script into debug to see what file it crashes on? Looking at the files copied, it stopped about half way though.

A recursive diff shows the (,v's) missing (expected) and a handful of other attachments not moved (ie non ,v files)

Cheers

-- TerryRankine - 21 Aug 2008

looking closer at the input file....

WebHome has 100k.zip as an attachment, but its not 'linked too' anywhere in the web. ie. there is no intext reference to it.

What will publish contrib do with this file?

-- TerryRankine - 21 Aug 2008

Hi Crawford, we have many plugins installed but this is the only plugin where I see the error. We have RequireRegistrationPlugin enabled which could refer to the filter.

-- PeterJones - 02 Sep 2008

Hello!

I'm using PublishContrib in a German speaking environment and get the following error:

Attachments in documents with umlauts in the document name cannot be included because the name gets url-ified and therefore the serverpath to the attachment doesn't fit the real path. For example:

  • Document name: NameWithÜmlaut
  • Attachment: someattachment.pdf
  • Real serverpath:
    ../pub/Web/NameWithÜmlaut/someattachment.pdf
  • Path as it appears in PublishContrib:
    ../pub/Web/NameWith%DCmlaut/someattachment.pdf
Environment is TWiki Fri Mar 31, 2006, build 9626. Plugin API V1.1. Site-locale is de_DE-ISO-8859-1.

Any ideas?

-- JoachimBlum - 04 Sep 2008

Joachim: We've had similar issues with published files and "un-wiki-like" file names. We couldn't find a way to solve it within TWiki or Publish themselves and had to create some Apache RewriteRule directives to send requests to the proper path.

-- JohnDeStefano - 05 Sep 2008

John, thanks for the hint. I'll try that.

-- JoachimBlum - 09 Sep 2008

Regarding the missing attachments and attachments table, I also ran into this problem. I could verify that the attachments table worked using view and the appropriate ?skin...= parameter, but when using PublishContrib there was no attachments table in the static HTML.

It is working for me now after I added the line mentioned in the attached patch, PublishContrib-attachments-TWiki-4.0.5.patch. BTW, I know very little about the internals of TWiki; I added the line because I saw that View.pm did this but Publish.pm did not.

I'm guessing this is only an issue because my TWiki installation is so old. It's what I got by using apt-get on my Debian install: TWiki-4.0.5, Tue, 24 Oct 2006, build 11822. Maybe this is the problem that the others have encountered.

-- DeanFerreyra - 12 Sep 2008

We're seeing a problem rendering simple javascript in the published web page. Please see the details in the following bug report. I just thought I'd also check here to see if anyone has any suggestions. TWikibug:Item6284

-- DevinBougie - 2009-07-06

I replied at TWikibug:/Item6284

-- PeterThoeny - 2009-07-06

Two points.

Checking existence of $TWiki::cfg{PublishContrib}{Dir} doesn't look consistent since $TWiki::cfg{PublishContrib}{Dir} is created shortly after that part.

The code leaks file descriptors and fails to process many topics. Finish()ing each TWiki object resolve it.

--- lib/TWiki/Contrib/Publish.pm        2008-12-08 18:55:57.883838511 +0900
+++ lib/TWiki/Contrib/Publish.pm.patched        2009-09-16 21:37:22.328463707 +0900
@@ -66,9 +66,9 @@
     unless ( defined $TWiki::cfg{PublishContrib}{Dir} ) {
         die "{PublishContrib}{Dir} not defined; run install script";
     }
-    unless( -d $TWiki::cfg{PublishContrib}{Dir}) {
-        die "{PublishContrib}{Dir} $TWiki::cfg{PublishContrib}{Dir} does not exist";
-    }
+#    unless( -d $TWiki::cfg{PublishContrib}{Dir}) {
+#        die "{PublishContrib}{Dir} $TWiki::cfg{PublishContrib}{Dir} does not exist";
+#    }
     unless ( $TWiki::cfg{PublishContrib}{Dir} =~ m!/$!) {
         die "{PublishContrib}{Dir} must terminate in a slash";
     }
@@ -536,6 +536,7 @@
     $this->{archive}->addString( $tmpl, $topic.$filetype);
 
     $TWiki::Plugins::SESSION = $oldTWiki; # restore twiki object
+    $twiki->finish();
 }
 
 # rewrite 

-- HideyoImazu - 2009-09-24

Thanks for reporting this back, Imazu-san!

-- PeterThoeny - 2009-09-28

Not sure why this contrib has been discontinued. It seems to work well and has functionality that is not provided by the PublishWebPlugin.

-- ThomasWeigert - 2011-11-27

Anybody who has a need for it can pick up the development of this contrib.

-- PeterThoeny - 2011-11-27

The following lines should be added to Publish.pm after line 631:

    # Set the meta-object that contains the rendering info
    $twiki->enterContext( 'can_render_meta', $meta );

-- ThomasWeigert - 2011-11-27

I needed to export a TWiki web as static HTML files for off-line use. This contrib basically worked but there were shortcomings. So I've made the following enhancements.

Bug fixes

  • it didn't work with a web housed in non-default disk on an installation UsingMultipleDisks
  • An HTTP response header kind of string is displayed on the result page
  • PUBLISH_INSTANCE needs to be eliminated because it allows access to an arbitrary file on the server
  • Both in inclusions and exclusions input fields
    • "?" meant a character or nothing. It's supposed to mean a character
    • Spaces after a comma were not ignored. So "Abc, Def" meant "Abc" and " Def"
  • enable/disable plugins is harmful in Fast CGI and mod_perl. So an option is needed to disable the feature
  • inefficiency -- each published topic was read twice
  • if access restriction is set by "Edit settings" rather than the topic text, that restriction is not observed
  • If a css file has url('data:...'), it was mis-recognized and an error occurs
  • If A*,B* was specified as inclusions, it was translated into ^A.*|B.*$ rather than ^(A.*|B.*)$, which resulted in totally unexpected behavior

Enhancements

  • Documentation improvements
  • A TWiki admin may not want to provide some output format. There need to be ways to disable some formats.
  • As ThomasWeigert pointed out on 2011-11-27, there was no way to put attachment list on a published page. There need to be a way while leaving the current behavior as default.
  • You may want to set TWiki variables while publishing. For example, you probably want to disable tool bars having Edit, Attach, Raw view, etc on published topics. You can achieve that by setting PUBLISHVAR_ _VAR_NAME_. e.g. Set PUBLISHVAR_READONLYSKINMODE = 1
  • Links to other topics may be written in absolute URLs, which is not a good practice but some do anyway. There might be URLs not matching the TWiki::getScriptURL("view") value but still work. There need to be a way to specify such URLs in a regular expression.

-- Hideyo Imazu - 2016-01-15

Thank you Hideyo-san for resurrecting this extension! I changed the TopicClassification from ObsoletePluginPackage back to ContribPackage.

-- Peter Thoeny - 2016-01-15

I've tried using this plugin on version 6.0.2, but when you run publish from the command line, I get the following output:

[Sat Jul 16 02:55:43 2016] view: Content-type: text/plain

[Sat Jul 16 02:55:43 2016] view:

[Sat Jul 16 02:55:43 2016] view: Perl error when reading TWiki.spec:

[Sat Jul 16 02:55:43 2016] view: Please inform the site admin.

[Sat Jul 16 02:55:43 2016] view: BEGIN failed--compilation aborted at /usr/lib64/perl5/TWiki.pm line 577.

[Sat Jul 16 02:55:43 2016] view: Compilation failed in require at /var/www/twiki-6.0.2/bin/view line 41.

[Sat Jul 16 02:55:43 2016] view: BEGIN failed--compilation aborted at /var/www/twiki-6.0.2/bin/view line 41.

As a note, we previously used a perl script (not developed by or anyone else on our team) that also exported a TWiki to tar, gz, or created an iso file but since we upgraded to 6.0.2, it also provides this same error message. We haven't fixed that script yet, but the script essentially runs the /var/www/twiki/bin/view file on the topics you provide it. I haven't looked at the source code of this plugin, but I suspect that it does something similar. It should be noted that our TWiki runs fine and all files check out, but the way the script runs, it is trying to run the /var/www/twiki/bin/view outside of apache, which could be part of the problem and may lead to the solution.

-- Wayne Gillo - 2016-07-19

Sorry to keep you waiting. Let me confirm one thing. When you ran the "publish" script, was the current directoy the bin directory of TWiki? And can I see the error message displayed on the terminal window? Or was the message you posted above all you saw?

What did you see when you use the feature from http://your-twiki-server/cgi-bin/view/TWiki/PublishContrib? Did it work or not?

-- Hideyo Imazu - 2016-08-05

Please report problems / submit patches in the Bugs web

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatgz PublishContrib-HTMLNameEquivalence-2006-09-14.gz r1 manage 2.6 K 2006-09-14 - 09:51 MarcSCHAEFER Patch for preliminar support of other external names than CamelCase
Unknown file formatpatch PublishContrib-attachments-TWiki-4.0.5.patch r1 manage 0.5 K 2008-09-12 - 09:39 DeanFerreyra Fixes missing attachments and attachments table for me on TWiki-4.0.5.
Texttxt recursive-diff.txt r1 manage 12.2 K 2008-08-21 - 02:14 TerryRankine  
Edit | Attach | Watch | Print version | History: r114 < r113 < r112 < r111 < r110 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r114 - 2016-08-05 - HideyoImazu
 
  • 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.