# Ticket #3725 (new enhancement)

Opened 5 years ago

## NewHack should include stub in the wiki page detailing plugin enablement

Reported by: Assigned to: k0s otaku42 low TracHacks normal 0.11

### Description

all plugins are enabled in much the same way; the wiki page generated by going through the new-hack process should include a stub for how to enable the plugin, including relevant links to wiki pages on http://trac.edgewall.org

## Change History

### 09/15/08 19:54:22 changed by coderanger

• status changed from new to closed.
• resolution set to wontfix.

The module name isn't known directly, so this really wouldn't work well.

### 09/15/08 20:05:42 changed by k0s

• status changed from closed to reopened.
• resolution deleted.

### 09/15/08 20:06:07 changed by k0s

• owner changed from coderanger to k0s.
• status changed from reopened to new.

reassigning this to myself for study

### 09/29/08 16:20:35 changed by k0s

• priority changed from normal to high.

### 12/22/08 18:42:05 changed by k0s

• priority changed from high to low.

de-prioritizing; have other tickets to look at right now

### 09/06/09 01:21:17 changed by rjollos

• summary changed from new-hack should include stub in the wiki page detailing plugin enablement to NewHack should include stub in the wiki page detailing plugin enablement.

### 01/22/10 09:08:50 changed by rjollos

I'm in favor of this. Plugins are installed the same way, and a lot of pages have poorly written installation information. It would be better to point to a single page with plugin installation information, and have the author add their specific trac.ini options and installation of dependencies on their plugin's wiki page.

### 02/04/10 20:02:29 changed by AdrianFritz

Some brainstorm ideas for NewHackTemplate "Install and Configure" section at NewHackTemplate/InstallAndConfigureProposal.

### 02/04/10 21:15:53 changed by rjollos

I have a couple of comments/changes/suggestions:

1. Rather than using a fake plugin/macro name, generate the steps for a real plugin/macro and use one that is simple to install, very mature, and generally useful to most people. That way, someone can run through the whole set of steps for a real plugin and rule out simple permission and environment configuration issues. If that is successful, it should be straightforward for someone to extrapolate the steps to another plugin. Perhaps the FootNoteMacro would be a good one to use for the example.
2. My understanding is that there are really 3 ways to install: using easy_install, manual global installation, manual installation for a single Trac environment.
1. I think that each option should be clearly outlined with a full set of steps for each, as opposed to having a single set of steps with switches depending on the mode of installation (i.e. if installing this way, do this, otherwise do this). For example:
1. Manual installation - Global
2. Manual installation - Single Trac Environment
3. Automatic installation using easy_install
2. It would be nice to provide general guidance as to which is best to use in certain situations, particularly for someone new who doesn't understand the trade-offs.
3. Recommend that plugin authors/maintainers add a section, where appropriate, for an end user to test the plugin functionality. I have tried to do this with the FootNoteMacro, for instance: FootNoteMacro#Example.
4. Should there be separate instructions for Windows vs Linux? I have never worked with Trac on Windows.

### 09/16/10 01:57:26 changed by rjollos

I see that some work has been done here: Install. I'd be in favor of updating TracPlugins, renaming it to InstallingTracPlugins and then adding a stub to the NewHack template, such as:

== Installation ==
{{{
#!comment
Plugin authors should add plugin-specific installation information
below, including the module name for enabling the plugin by editing
trac.ini.
}}}
For generic installation information, see InstallingTracPlugin.

This section could be placed between the Source and Example sections.