The trac standalone can use Apache's htpasswd files for authentication. Although Apache creates an htpasswd file with format user:password, it understands files with additional components after those first two. For example, dokuwiki uses the format user:password:Real Name:email:groups to provide additional information on each user. Such a file also works with Apache and nginx HTTP Basic Auth; they just ignore the remaining fields. But tracd breaks, because it expects exactly two components.

Perhaps more importantly, other tools respect comments in htpasswd. So, for example, if you want to disable user joey12, you can comment out that user's line by putting # in front. But tracd just processes that as #joey12, which could potentially allow a login under that name.

This pull request adds the ability to handle those more general htpasswd file formats. It simply removes everything after a #, and then only takes the first two components of any remaining lines.

[Technically, Apache only considers a line a comment if it begins with #; I think this behavior is safer for htpasswd files, especially since this makes it less likely that this function will dump passwords to the error log.]

I would like to start getting some feedback on integrating this back into the main trunk. Here is what I have.

• New batch modify module.
• Batch modify UI integrated into query page.
• New permission (TICKET_BATCH_MODIFY)
• Added a new page to the TracGuide and updated the TOC macro.
• Wrote tests against new module.

I still have a couple of outstanding issues as well.

• One of the new batch tests fails. Right now I think the problem is with the test itself. I cannot reproduce the error through a running Trac instance. I'm probably doing something wrong with the EnvironmentStub.
• I don't have any tests on my query page integration. Are there any examples of permission testing I can look at? I want to test that batch data is only added when the user has the appropriate permission.
• The documentation page I added to the wiki feels off. I don't feel like I'm explaining the configuration options in a clean way. Suggestions welcome.

Purpose: enable Trac to determine MIME types for syntax highlighting not just simply by file extension, but more powerfully by regex file name matching. This is done by introducing a new trac.ini parameter 'mime_map_patterns' in section [mimeviewer].

How to test:

• Add this to trac.ini, section [mimeviewer]: mime_map_patterns = text/x-python:.py.
• Add a Python source file to your source code repository, but rename it to something containing 'py' without the defauly '.py' extension, e.g. 'test_py_file'
• Restart Trac
• Check in a web browser if your new repository file is correctly highlighted as a Python file

This patch was initially developed for the Freetz [1] project by Alexander Kriegisch and used there [2] successfully ever since it was suggested in Ticket #10437 [3] in October 2012.

Freetz usage exampe: mime_map_patterns = text/x-kconfig:.*Config.in.*|external.in.*|standard-modules.in

[1] http://freetz.org [2] http://freetz.org/browser/trunk/tools/developer/mime_map_patterns.trac.patch [3] http://trac.edgewall.org/ticket/10437#comment:5

Purpose: enable Trac to determine MIME types for syntax highlighting not just simply by file extension, but more powerfully by regex file name matching. This is done by introducing a new trac.ini parameter 'mime_map_patterns' in section [mimeviewer].

How to test:

• Add this to trac.ini, section [mimeviewer]: mime_map_patterns = text/x-python:.py.
• Add a Python source file to your source code repository, but rename it to something containing 'py' without the defauly '.py' extension, e.g. 'test_py_file'
• Restart Trac
• Check in a web browser if your new repository file is correctly highlighted as a Python file

This patch was initially developed for the Freetz [1] project by Alexander Kriegisch and used there [2] successfully ever since it was suggested in Ticket #10437 [3] in October 2012.

Freetz usage exampe: mime_map_patterns = text/x-kconfig:.*Config.in.*|external.in.*|standard-modules.in

[1] http://freetz.org [2] http://freetz.org/browser/trunk/tools/developer/mime_map_patterns.trac.patch [3] http://trac.edgewall.org/ticket/10437#comment:5

I was looking for a solution to enhance the usefulness of trac search results. Stock trac seems to sort search results by the date of last change, which might not always be what users expect. Looking for a medium solution between using complete indexing server as suggested in https://trac.edgewall.org/wiki/AdvancedSearch and the current solution, I suggest a medium solution (with regard to both complexity and quality), ordering the results based on occurrence of the search word in page/ticket title, headers and content.

The ISearchSource get_search_results() gets an optional sixth value in the return tuple called order which is supposed to contain a quadtuple which is to be composed of

• rating for pagename/filename
• rating for headings
• rating for description/content
• timestamp The order parameter is then used to sort search results. The ratings are evaluated in above order. In each case, a higher value will signify a more relevant search result.

I was looking for a solution to enhance the usefulness of trac search results. Stock trac seems to sort search results by the date of last change, which might not always be what users expect. Looking for a medium solution between using complete indexing server as suggested in https://trac.edgewall.org/wiki/AdvancedSearch and the current solution, I suggest a medium solution (with regard to both complexity and quality), ordering the results based on occurrence of the search word in page/ticket title, headers and content.

The ISearchSource get_search_results() gets an optional sixth value in the return tuple called order which is supposed to contain a quadtuple which is to be composed of

• rating for pagename/filename
• rating for headings
• rating for description/content
• timestamp The order parameter is then used to sort search results. The ratings are evaluated in above order. In each case, a higher value will signify a more relevant search result.

I was looking for a solution to enhance the usefulness of trac search results. Stock trac seems to sort search results by the date of last change, which might not always be what users expect. Looking for a medium solution between using complete indexing server as suggested in https://trac.edgewall.org/wiki/AdvancedSearch and the current solution, I suggest a medium solution (with regard to both complexity and quality), ordering the results based on occurrence of the search word in page/ticket title, headers and content.

The ISearchSource get_search_results() gets an optional sixth value in the return tuple called order which is supposed to contain a quadtuple which is to be composed of

• rating for pagename/filename
• rating for headings
• rating for description/content
• timestamp The order parameter is then used to sort search results. The ratings are evaluated in above order. In each case, a higher value will signify a more relevant search result.