Tags:
create new tag
, view all tags

Bug: TablePlugin does not load

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

TWiki version: DakarRelease
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  

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

Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2005-07-12 - CrawfordCurrie
 
  • 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.