• RENAMED FROM PublishAddOn
• This is the original web publishing tool. Use the PublishWebPlugin to maintain your website collaboratively in TWiki.
Contents:
--
CrawfordCurrie - 27 Feb 2006
WIBNIF (wouldn't it be nice if....)
- 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 was a tar.gz option as well as zip -- CrawfordCurrie - 27 Apr 2005
- You could delete previously generated zips from the browser -- CrawfordCurrie - 27 Apr 2005
- You could choose a name for the generated zip -- CrawfordCurrie - 27 Apr 2005
- 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
- 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
- The Attachement on the page for the Cairo version had the Cairo code, not the Dakar version. -- EricHanson - 05 May 2006
- 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
- 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
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;
- Make sure LWP is installed and is at the latest version
- Check the other dependencies of the contrib at the same time
- Check what other apache modules are installed
- 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
--
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
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
Please report problems / submit patches in the Bugs web