Docs do not reflect difference in wiki processing between custom text and textarea fields

[jj33@…]

In ​http://trac.edgewall.org/wiki/TracTicketsCustomFields it is stated that both type=text and type=textarea fields can be set to format=wiki. This is true, but the contents of the two fields are processed differently. Specifically, macros aren't expanded in type=text fields even if they only generate one line of text.

The choice to have these two fields behave differently seems to be a conscious choice, following the comments and commits from ticket:1791.

This is not consistent with the behavior of built-in fields. Typing a macro into the keywords field will cause the macro to be expanded.

I don't really have a problem with the current behavior, but for consistency's sake, either custom type=text fields should behave the same as built-in fields when format=wiki or the ​custom field docs should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get.

[Christian Boos]

Replying to jj33@…:

… Specifically, macros aren't expanded in type=text fields even if they only generate one line of text.

Ok, this is a known limitation and we hope to improve this in future iterations of the WikiEngine.

Typing a macro into the keywords field will cause the macro to be expanded.

??

… or the ​custom field docs should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get.

Yes, we should add this information, except that I don't know of any builtin field that gets full wiki processing besides the description (which is a textarea)… certainly not keywords ;-)

[John Jetmore <jj33@…>]

certainly not keywords

Wow, you're absolutely right of course. My mistake is that the macro I was testing with returns the original macro text (like [[CRM(1234)]]), but wrapped in a hyperlink. When testing that macro in a custom test field, it returned "[[CRM(...)]]". When I tested it in keywords, it returned a hyperlinked "[[CRM(1234)]]". Unfortunately I didn't mouse over it to see that it's a link to a keyword query, not the link the macro would actually produce. Oops.

Anyway, thanks for looking at this. I guess I just fall back to my original "the docs should state that format=wiki doesn't work the same for type=text and type=textarea".

[Ryan J Ollos]

It was recently discussed on ​mailing list that it would be nice if wikified data for textarea fields (description and custom fields) was formatted to wiki when displayed in a column. Wikified data is currently only formatted to wiki when displayed in a row.

How about the following patch? It doesn't preserve whitespace in the wiki markup, but at least the wiki content is formatted to wiki.

trac/ticket/query.py

@@ -722 +722 @@
         cols = self.get_columns()
         labels = TicketSystem(self.env).get_ticket_field_labels()
         wikify = set(f['name'] for f in self.fields
-                     if f['type'] == 'text' and f.get('format') == 'wiki')
+                     if f['type'] == 'textarea' or
+                        f['type'] == 'text' and f.get('format') == 'wiki')
 
         headers = [{
             'name': col, 'label': labels.get(col, _('Ticket')),

Additional changes that preserve whitespace in the formatted text can be found in log:rjollos.git:t10352.

[Jun Omae]

The changes lead API changes for a custom field which is text as wiki in tags/trac-1.0.1/trac/ticket/templates/query_results.html@:84#L77​ (header.wikify → header.wikiline). I think that we should keep it because somebody might customize query_results.html or some plugins might access it using post_process_request.

[Ryan J Ollos]

I've made some changes in log:rjollos.git:t10352 to keep wikify variable in the dictionary unchanged. Does that look okay?

I wish I could come up with a better variable name than wikifyblock!

[Jun Omae]

I've made some changes in log:rjollos.git:t10352 to keep wikify variable in the dictionary unchanged. Does that look okay?

Looks good. Thanks!

[Ryan J Ollos]

Thanks for the review. I'll push the change, and try to address the documentation suggestions in this ticket.

[Ryan J Ollos]

Replying to John Jetmore <jj33@…>:

Anyway, thanks for looking at this. I guess I just fall back to my original "the docs should state that format=wiki doesn't work the same for type=text and type=textarea".

I added a one-liner here. Feel free to improve on it as you see fit.

[Ryan J Ollos]

Committed to 1.0-stable in [12235].

Replying to rjollos:

I wish I could come up with a better variable name than wikifyblock!

On merging to the trunk (which I should have checked before committing to 1.0-stable), I found that some significant changes are needed on merge. Some nice cleanup was done in [11330] which makes my patch on the trunk quite a bit cleaner (removing the need for the wikifyblock variable), but the changeset on the trunk is significantly different now. I committed the changes on the trunk in [12236]; please let me know if you spot any issues.

[Peter Suter]

Would it make sense to add 'format': 'wiki' to the description field​ (and perhaps some others as well) so that you don't have to special case it here​?

[Ryan J Ollos]

Replying to psuter:

Would it make sense to add 'format': 'wiki' to the description field​ (and perhaps some others as well) so that you don't have to special case it here​?

Looks like a good idea to me at least. I'll prepare and test the change if there are no arguments against it. It seems most suitable for the trunk rather than 1.0-stable since it results in a change to the API that could effect plugins, so perhaps I should tentatively plan to target the change there?

[Peter Suter]

Sounds good.

[Ryan J Ollos]

Proposed refactorings can be found in attachment:t10352.patch​, including Peter's suggestion from comment:12 and a minor refactoring to introduce a wikitext variable, which I think makes the code more readable and consistent.

[Ryan J Ollos]

Patch from comment:15 committed to trunk in [12244].