Macro load failure : error message not very helpful...

[jouvin@…]

Hi,

If you try to use a macro in a wiki page and its fails to load because of an error in the macro code, you get an error message saying 'file not found'. For example :

Error: Failed to load processor redirect No macro named redirect found

This happens because redired is trying to load trac.WikiFormatter that no longer exists. It would be nice to have an error message saying there is an error in the macro (and possibly return the error) like it is the case in the log file if you enable logging.

[Christian Boos]

While it would be possible to propagate the appropriate error message, I think that it would unecessarily complicate the code, for not much benefit: it's a setup issue, and can be solved only by the admin, who has access to the log anyway (or can enable logging to sort things out).

Maybe a simple advice for checking the log output would be enough?

No macro named [[redirect]] found, check Trac log for more details.

[dpeterson <dpeterson@…>]

Well, I downloaded the ShowPath.py macro (from MacroBazaar) into the wiki-macros directory and it doesn't run - I'm getting the error message mentioned above.

No macro named [[ShowPath]] found

So I went to the trac.log which is set for DEBUG level logging, and it has an equally useless message of:

15:19:22 Trac[macros] ERROR: Failed to load wiki macro ShowPath.py (Macro ShowPath not found)

How do I find out why this macro isn't working? One of these methods should definitely be propagating the error message.

[Christian Boos]

Well, I think we can't given away to much in case of an error, unless the viewer has some special privileges (like being TRAC_ADMIN). In that case, the full backtrace could probably be provided. Otherwise, something like the solution in comment:1 seems enough (the message could rather be "inform the Trac administrator about the error").

[Emmanuel Blot]

Replying to cboos:

Otherwise, something like the solution in comment:1 seems enough (the message could rather be "inform the Trac administrator about the error").

What about triggering an event so that a notification could be sent to the admin if a macro fails to render? - this should be optional, obviously.

[Christian Boos]

WikiEngine refactoring and related fixes postponed.

[osimons]

I think this is a non-issue, but if anything we could perhaps touch up on the error to include the most likely cause of this error in normal use: Typos. Who remembers all the macro names or processor directives? Sometimes you just get it wrong, sometimes you have a vague idea and try a few alternatives.

As far as I know, we now have no way of distinquishing between a macro that is mistyped, and a macro that exists but did not load because of error. Neither exists as far as Trac is concerned. And, during rendering the error would be uneventful - no useful information on why it didn't load as with current macro-as-a-plugin the loading and rendering is not directly connected.

Raising this all the way to an error page w/ possibly a traceback would make regular editing and previewing a disaster. And a saved page with a bad macro… Need to issue all users with the ?action=edit trick… :-)

Personally I think it is fine - someone installing the macro would know what it means, a user mistyping would know. It is probably just Trac itself that doesn't know :-)

wontfix vote from me.

[dpeterson]

If the log actually contained a traceback of why the macro couldn't be loaded (not all cases are a mismatch between the typed name and the name on the filesystem, sometimes there are internal errors in the code itself) then I'd be fine with not showing anything in the rendered web page.

[osimons]

Replying to dpeterson:

If the log actually contained a traceback of why the macro couldn't be loaded (not all cases are a mismatch between the typed name and the name on the filesystem, sometimes there are internal errors in the code itself) then I'd be fine with not showing anything in the rendered web page.

If there is a traceback when loading a plugin due to errors in the code, there will also be an entry in the log from the first request after server restart which is when plugins gets loaded (before use).

With current version (0.11) the filename and macro/plugin name is no longer connected, so technically you can have many macros in a single file - or a macro inside some other larger plugin. Trac can only know the macros that actually DID load successfully - in use everything else will look like typos calling macros that does not exist.

[osimons]

I'm closing this for lack of anything useful that can reasonably be done to implement the request and further improve the information on non-loading/non-existing macros and plugins. The current logging should be sufficient, and it provides information for detecting problems for further research.

If anyone has good ideas to improve this, feel free to reopen the ticket of course.