All plugins shipping with the
DakarRelease should be activated.
DakarRelease ships with the following plugins:
- ActionTrackerPlugin
- CommentPlugin
- DefaultPlugin
- EditTablePlugin
- EmptyPlugin
- InterwikiPlugin
- PreferencesPlugin
- RenderListPlugin
- SlideShowPlugin
- SmiliesPlugin
- SpreadSheetPlugin
- TablePlugin
- TestFixturePlugin
However, only the following plugins are activated successfully:
- CommentPlugin
- InterwikiPlugin
- PreferencesPlugin
- SmiliesPlugin
- SpreadSheetPlugin
%FAILEDPLUGINS% shows FindElseWherePlugin as having failed due to no plugin topic.
All other plugins seem to be bombing out somewhere due to some problem. Strangely enough, all these plugins have no code errors (i.e., they can at lesat be loaded under
perl -d.
Test case
Just look in %ACTIVATEDPLUGINS%
Environment
--
ThomasWeigert - 10 Jul 2005
Impact and Available Solutions
Follow up
This is not a bug.
You need to run
bin/configure
--
AntonAylward - 11 Jul 2005
Fix record
Discussion
NO NO NO!
All plugins shipping with the
DakarRelease should NOT NOT
NOT be activated by default.
For example, I'm running a live site. I do not NOT
NOT want
activated.
I run
bin/configure to select the ones I
DO want activated.
I think your problem is that the
.cgf file that was fetched from the Subversion stored by
svn up and over-wrote what you had now has just those you mention marked as active and you haven't run =bin/configure to turn on the ones you want and off the ones you don't.
This major change, the need to run
bin/configure (quite possibly every time you do a
svn up since you might zap something you thought you had customized) caught me out as well.
The real problem here is that a
svn up zaps what you might have customized and no-one tells you about it. To some degree its the code getting ahead of the documentation; to some degree its that the documentation doens't emphasise what is new (I keep doing
svn diff and
svn log and checking the revision diffs of various topics in Codev now, I've been bitten and I'm paranoid); to some degree its a limitation of the way Subversion works.
But there is also the small matter of people overwriting other's changes. This has now made a complete mess of the default access permissions in the TWiki and Main webs in the
DEVELOP branch.
--
AntonAylward - 11 Jul 2005
Thanks,
Anton that makes sense. I agree that not all plugins need be activated by default. I was more concerned about that these were broken as in the past they would have loaded. There is no indication that the plugins are disabled...
I would have thought that plugins that are not enabled should have shown up on the %DISABLEDPLUGIN% list... not just don't work...
--
ThomasWeigert - 11 Jul 2005
OK, so the report here is really "Disabled plugins don't show up in DISABLEDPLUGINS", right? Correct. As documented in
http://twiki.org/cgi-bin/view/Codev/DakarReleaseNotes#Plugins
INSTALLEDPLUGINS and DISABLEDPLUGINS are both removed from the
DakarRelease, since they duplicate/displace the much simpler interface in
configure.
Please add a report in the Bugs web if you think this is critical. Personally I think that anyone who is in a position to enable/disable plugins is in a position to run
configure and view the list there but hey, what do I know? I corrected the default settings and documentation of INSTALLEDPLUGINS and DISABLEDPLUGINS in
SVN 4577.
Oh, and
FindElsewherePlugin isn't checked in; where are you picking it up from?
--
CrawfordCurrie - 11 Jul 2005
Sorry for the false alarm. I did not realize we need to run
bin/configure. Do I need to do this everytime I update svn?
On
FindElsewherePlugin... true, it is not in the installation. But %FAILEDPLUGINS% gives an error report about it. Somewhere in the installation there must be something causing it to thing it should have this plugin.
Greping through the installation I find the line
$TWiki::cfg{Plugins}{FindElsewherePlugin}{Enabled} = 1;
in
-
./lib/.svn/text-base/TWiki.cfg.svn-base
-
./lib/TWiki.cfg
which probably explains the problem...
I hope that we can still order the loading order of plugins somehow?
--
ThomasWeigert - 11 Jul 2005
Yes, in the same place you enable the plugins in the
configure script there is a setting for the plugin ordering.
--
RafaelAlvarez - 11 Jul 2005
configure only writes
LocalSite.cfg so as long as no-one renames a setting you shouldn't have to re-run it when you
svn up.
--
CrawfordCurrie - 11 Jul 2005
So let's get the
FindElsewherePlugin setting out of the distribution and then we are all set...
--
ThomasWeigert - 11 Jul 2005
It was never in it. Removed the enable switch,
SVN 4594
--
CrawfordCurrie - 12 Jul 2005