Mod Manager Enhancements TNG v12

TNG version:

≥ 12.0.0

The following Mod Manager enhancements were made in TNG v12:

• new options
  • renamed Analyzer tab to Analyze TNG Files
  • added an option to display the View Parse Table tab
  • added an option to display the Recommended Updates tab
  • added delete folder capability when deleting a mod
• added Select to the filter pull down list
• added a Delete button to the Select filter list
• added new processing tags
• added conditional processing tags
• added new processing flags
• added support for $modspath and $extspath in %description:
• tightened syntax and better error detection
• new Recommended Updates tab

New Options

New options were added to the Mod Manager for TNG v12 that require that you update the mmconfig.php file. The first time you access the Mod Manager you will be prompted to update the Mod Manager Options by opening the Options tab and doing a Save.

Analyze TNG Files

The Analyzer tab was renamed to Analyze TNG Files.

View Parser Table

When a mod is having a problem, the first thing we need is to look at the parser table to see if mod tags are being handled correctly.

Mod Manager in TNG v12 provides a simple utility that is invoked from View Parser Table tab to analyze how the Mod Manager is parsing the mod cfg file. You can select a mod from the list and view the parser table results.

Note that you must enable the Show Other Developer tools in the Options screen to display the View Parser tab.

Note that the parser table for an individual mod can be displayed by clicking the Mod Name in the Mod List, if the option is enabled.

Note that mod developers who do not follow the Mod Guidelines of using all lower cases for the cfg file name may make it a challenge to find the correct cfg file since it does not match the name in the Mod List.

Delete Folder

The updated Mod Manager will now delete the folder associated with a mod when deleting the mod

Note that you must enable the Allow Delete support folder when mod is deleted in the Options, Other section for the folders to be deleted.

For example, the Delete | Cousin_marriages | File deleted | Admin User will show the following in the View Log

• Deleting cousin_marriages_11.0.0.0q.cfg
• Folder cousin_marriages Deleted
• cousin_marriages_11.0.0.0q.cfg File deleted

To avoid problems, mods should use a folder name that ties the folder to a given mod version as indicated in the Mod Guidelines

Select Filter

The Mod Manager Status filter allows you to process more than one mod at a time. You can filter the list of mods so that it displays only mods that have a certain status, and then perform an action on multiple mods in the result set. With TNGv12, there is a new filter called "Select":

The Select filter is not about processing multiple mods at once, but about performing multiple operations on one mod, or on a short list of mods. When you chose "Select" in the filter drop-down list, and click "Go", you'll get a list of all mods, with checkboxes next to each. Next, check the box next to specific mods and click the "Select" button.

Here you'll see that I've selected three related mods that affect each other, and not all of which have the same status. Also note that, for the Select filter to be useful, you want to make sure that the "Lock" checkbox is checked.

Now, you can process one of the mods by expanding its status cell and clicking on an action button, at which point that mod will be processed, and the same list of three mods will be redisplayed. Of course, at least one of those mods will now have a new status. You can then perform another action on one of the mods, and so on.

The Select filter is also useful to mod developers who intend to process a single mod over and over during debug/test cycles. If you select that single mod and lock it in place, you can install it, then uninstall it, then install it, etc.

Delete Button on Select List

The Select filter list can be used to Delete mods in all status provided that you have updated the Options in the Other section to Yes for

• Allow Delete Selected of Partially Installed Mods
• Allow Delete of individually Installed Mods

The Delete capability on the Select filter list provides the developers a handy way to clean up their developer sandbox where they might have multiple versions of the same mod installed.
TNG Users may not want to enable the above options. If you also want to delete the support folder associated with the mod, you also need to enable

• Allow Delete support folder when mod is deleted

New Tags

note tag

The %note: tag can be used to define messages that are displayed in the un-expanded Status column of the Mod Manager list. It is typically used to alert the user to mods that have special characteristics or that have conflicts and other relationship with other mods.
The %note: tag can be in any place in the mod .cfg file, for example above the %location:% that causes a conflict. It can also be used with the %private: tag

The Select Filter screen shots above happens to show such a message, and more specific examples follow.

• A simple message indicating that the mod coordinates with another mod. Details of that relationship would be found in the expanded Mod Manager List status cell, or in the mods's Wiki article

%note:Coordinates with the Admin Places Search mod%

which generates the message shown on line 6 in this screen clip:

• Another simple message indicating the the mod changes the database and has a database setup program.

%note:DB Setup%

This message appears in the un-expanded status cell, and is still visible at the top of the cell when the status cell is expanded, as shown here. Note that the mod description displayed in the expanded cell provides more information about the mod's database setup.

You can click on the [Expand] link on the right to display the hidden section or [Collapse] to hide the section.

Styling can be applied to %note tag messages, as shown in the following examples, which show how you might convert some of the tags that were defined in the TNGv11 Mod Manager Note Tags mod.

• ConflictsWith message - Used when the mod is known to conflict in some way with another mod.

%note: <strong><span style='color:red;'>ConflictsWith:</span> Mobile Site Enhancements <span style='color:blue;'>which must be installed first</span></strong> %

which generates the Status column message shown in line 13 here:

File:Mod Manager 12 conflict note.png

• DependsOn message - when a mod depends on another for certain functionality to work.

%note: This mod will suppress the Geocode globe if placelevel is == "-1" (Do not geocode). 
<strong><font color=red>DependsOn</font> the Admin Places Geocode</strong> to set the Do not geocode%

which generates the message in line 13 in this screenclip:

File:Mod Manager 12 dependson note.png

• PreReqs message - For other mods that must be installed before this mod in order for this mod the work.

%note: <strong><span style="color: red">PreReqs</style></strong> You <strong>MUST</strong> have the Ancestors Map Mod <strong>AND</strong> the Google maps - Add 4 more Place Levels Mod installed before installing this mod.%

which generates

PreReqs You MUST have the Ancestors Map Mod AND the Google maps - Add 4 more Place Levels Mod installed before installing this Mod.

File:Mod Manager 12 prereq note.png

While the implementation is slightly different, the %note: tag replaces most of the tags that were implemented by the Mod Manager Note Tags mod in TNGv11.

author tag

The %author: tag is used to provide information about the author of the mod. It should be used to replace the Mod Developer is string previously used in the %description section. It has has two parameters:

• The author's name, and
• An optional URL, which is used to turn the author's name into a hyperlink. The URL can refer to the author's TNG Wiki profile page, or any other page that provides information about the author's mods.

%author:Robin Richmond:https://tng.lythgoes.net/wiki/index.php?title=User:Robinrichm%

The author's name is shown in the 'expanded Mod Manager List status cell, just below the action buttons:

If more than one person worked on a mod, then you can

• Display each name as a hyperlink by specifying a separate %author: tag for each author, or
• List as many names as you want as the first parameter of a single %author: tag, though with at most one URL.

The many different representations of the 'Author' or 'Mod Developer' in the %description section of the mod's .cfg file can all be replaced by the the %author: tag. The TNGv12 %author: is only slightly different from the !@#author: tag that was implemented by the Mod Manager Note Tags mod in TNGv11.

mkdir tag

The %mkdir tag can be used to create new directories (folders) needed for the mod. If you use copyfile2 to copy files to a directory that you just created, you should use the new 'Provisional flag' (^) so that the %copyfile2 commands that follow the %mkdir tag will not be flagged with a 'Cannot Install' error. (See the example in the Provisional flag section below.

private tag

The %private: tag is used to flag private mods; that is, mods that are intentionally not published on the TNG wiki. When you specify the %private: tag, the message Private Mod is displayed in the un-expanded status cell of the mod list. You can also provide a %private: tag argument, which is a message that is displayed immediately after Private Mod. The message can have HTML markup.

Here are three private mods: The first has no argument. The third has the argument "Intend to publish someday", and the third has no %private tag argument, but does have a %note: tag. The note is distinguished from the %private: tag argument only by a couple of spaces in front of the note.

As you would expect, none of the three mods above have a Wiki icon, since none of them have Wiki articles. But private mods can have wiki articles, as in this case: In this example, the %private: tag contains a formatted message that describes a private modification to a published mod.

which generates

vinsert tag

Note that since TNG v12 moved the Template Settings to the tng_templates table, the usefulness of this tag is now questionable.

The %vinsert: tag can be used when inserting template variables in the templateconfig.php file that can be dynamically changed by the user in the Admin > Setup > Template Settings for the template. When changes were made previously the mod showed as Partically installed and the template variables section showed as Not Installed since the lines no longer matched.

The new %vinsert: is a block-type optag that allows inserting variables into config files whose values TNG or other parties may rearrange or modify independently of the Mod Manager. It is similar to a %location% tag, but it only checks the insertion point for the variable names and not the values

When installed, modlister only checks for the existence of the variables in the target file and ignores their values.

When uninstalled, modremover deletes the variables and their values, whatever they are at that time.

Conditional Processing Tags

The Mod Manager in TNG v12 adds some conditional processing tags

• to check on the existence of a file
• to check on whether a text string exists
• to check the TNG version
• to exit the test a goto tag is provided

Along with the %note: that allows you to warn users of conflicts or install dependencies, the conditional processing tags provide the tools to possibly resolve the conflicts by taking different paths in the mod cfg file when installing or verifying that code is installed. The following screen capture shows both situations where the %note tag is used to indicate an install sequence and conditional tags used to resolve the conflict and install sequence.

Note that by using the %textexists tag the conflict was resolved in the Mobile Site Enhancements mod and the message in the conflicting Add DNA Test Results mod updated to show what version of the Mobile Site Enhancements mod must be installed.

fileexists tag

The %fileexists:filename:label% tag is a conditional tag (essentially an If/GoTo statement) that can bypass other tags, such as tags that would try to create or copy a file that may already exist. With a %fileexists tag:

1. The first argument must be a filename using a relative path, just like a %target or %copyfile command,
2. The second argument must be a label, using the new %label tag, described below, and
3. The newfile or copyfile tags between the %fileexists tag and the %label tag must use the new 'protect' flag, the tilde (~), described below.

The following is how the Census Plus International mod implemented the new %fileexist: tag to preserve the user's settings across uninstall and install of the new version of the mod.

%fileexists:$extspath/cp_settings.inc:skipit%
%newfile:~$extspath/cp_settings.inc%

...file contents...
%fileend:%
%label:skipit%

Mod Manager processing works as follows

• if the file does not exist, the Mod Manager uses the %newfile and %filend tags to create it.
• if the file exists, the Mod Manager goes to the %label:skipit% and bypasses creating the file.
• when uninstalling the mod, the ~ (tilde) in the %newfile directive prevents the file from being deleted. The protect flag by not deleting the file on an uninstall or clean up, thus preserves the mod settings to be used when the mod is installed again.

The Parser Table entry will display the following information when evaluating the %fileexists: conditional

textexists tag

The %textexists:label% tag is a conditional tag (essentially an If/GoTo statement) that can be used to test whether the code has been modified so that two or more paths could be taken and the conflict between two mods can be resolved and not show a Partial Installed status for the conflict area With a %textexists: tag

1. The first argument must be a label, using the new %label tag, described below
2. The %textexists: tag must also follow a %target: tag, that is be within a %target:script% section

The %textexists tag allows you to test for two or more different versions of a location. That is be done by daisy chaining two or more %textexists tags. In other words, if first version of location does not exist, test for the second version; if the second versions does not exist, try to install over the TNG factory version. If that does not exist you will get a bad location error (the line number will show you the bad location text in the mod config file). Pseudo code it would look like this:

• test for version 1 and goto processing label-1 if it exists
• test for version 2 and goto processing label-2 if it exists
• try to install default location (over TNG factory location)

You can click on the [Expand] link on the right to display the hidden section or [Collapse] to hide the section.

The following is an example on how the code was changed in the Mobile Site Enhancements mod to resolve the Partial Install - Bad Target conflict when the Add DNA Test Results mod is installed. Notice that line 12 and 28 show a note that was added to the %location: to indicate what path is being taken by the Mod Manager when installing the mod

	/****  Start of conditional logic to determine if conflicting mod is installed or not

%textexists:DNA-test_installed%
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}$toggleicon</td>\n";
%end:%

%textexists:DNA-test_notinstalled%
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}&nbsp;</td>\n";
%end:%

%label:DNA-test_notinstalled%
%location: <span style="background-color:yellow;color:black">DNA Test Results mod not installed condition</strong></span>%
			$persontext .= "<col class=\"labelcol\"/><col style=\"width:{$datewidth}px\"/><col />\n";

			$persontext .= "<tr>\n";
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}&nbsp;</td>\n";
%end:%
%replace:%
			$persontext .= "<col class=\"labelcol\"/><col class=\"eventdatecol\"/><col />\n";

			$persontext .= "<tr>\n";
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}&nbsp;</td>\n";
%end:%
%goto:continue%

//  Add DNA Test Results installed
%label:DNA-test_installed%
%location: <span style="background-color:yellow;color:black">Add DNA Test Results mod installed condition</strong></span>%
			$persontext .= "<col class=\"labelcol\"/><col style=\"width:{$datewidth}px\"/><col class=\"takenbycol\"/><col class=\"haplogroupcol\"/><col />\n";

			$persontext .= "<tr>\n";
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}$toggleicon</td>\n";
%end:%
%replace:%
			$persontext .= "<col class=\"labelcol\"/><col class=\"eventdatecol\"/><col class=\"takenbycol\"/><col class=\"haplogroupcol\"/><col />\n";

			$persontext .= "<tr>\n";
			$persontext .= "<td valign=\"top\" class=\"fieldnameback fieldname\" rowspan=\"$num_tests\">{$admtext['dna_tests']}$toggleicon</td>\n";
%end:%

	/****  End of conditional logic
%label:continue%
...

The Parser Table will display the following when evaluating the %textexists conditional

tngversion tag

The %tngversion: tag allows checking for a TNG version that falls between a start and end range of versions specified. If the user's version of TNG falls with the range, the conditional is true and processing jumps to the label.

%tngversion:range_start:range_end:label%

The %tngversion: tag has 3 arguments:

• the first TNG version to which the code applies
• the last TNG version to which the code applies
• the goto label for the Mod Manager processing

The range of version numbers includes both the low and high numbers provided. Only digits and decimal points are allowed for the range. Decimal points are removed and the number is padded with trailing zeros to four places for comparison purposes. That makes the examples below possible.

Examples

• %tngversion:1100:1111:skip_error%
• %tngversion:11.0.0:11.1.1:skip_error%
• %tngversion:11:12:skip_error% (1100 to 1200)
• %tngversion:10.2.0:11.1:skip_error% (1020 to 1110)

The next tag, where processing continues if the user's TNG version is outside the provided range, might be/could be: %description:This mod will not work with your version of TNG. Please goto [url for TNGWiki page] to download the correct version of the mod.% // This will be the second %description tag in the mod configuration file and it will override the first one in the listing. If the mod falls within the correct range, process skips this and proceeds to normal processing.

Of course there can be other reasons for testing the TNG version, perhaps to detect the correct target text.

You can click on the [Expand] link on the right to display the hidden section or [Collapse] to hide the section.

The following is an example on how the code was changed in the Citation Master mod to support more than one TNG version. Notice that the following example uses the note on the %location: tag in lines 9 and 32 to indicate which path the Mod Manager will take when processing this mod

	/* TNG version condition logic starts here

%tngversion:1110:1111:Use_TNG11.1.0%
%tngversion:1112:12:Use_TNG11.1.2%
%description: This version of TNG may not be supported by this mod%

%label:Use_TNG11.1.0%

%location: <span style="background-color:yellow;color:black">TNG 11.1.0-11.1.1 version </strong></span>%
if( $foffset ) {
	$foffsetstr = "$foffset, ";
	$newfoffset = $foffset + 1;
}
else {
	$foffsetstr = "";
	$newfoffset = "";
}
%end:%
%insert:after%
// BEGIN: Citation Master
// get a formatted source and insert it as the 'Preview' field
$pretty = citem_getFormattedSource($sourceID);
$sourcetext .= showEvent( array( "text"=>"Preview", "fact"=>$pretty ) );
// END: Citation Master

%end:%

%goto:continue%

%label:Use_TNG11.1.2%

%location: <span style="background-color:yellow;color:black">TNG 11.1.2-12 version </strong></span>%
if( $foffset ) {
	$foffsetstr = "$foffset, ";
	$newfoffset = $foffset + 1;
}
else {
	$foffsetstr = "";
	$newfoffset = 0;
}
%end:%
%insert:after%
// BEGIN: Citation Master
// get a formatted source and insert it as the 'Preview' field
$pretty = citem_getFormattedSource($sourceID);
$sourcetext .= showEvent( array( "text"=>"Preview", "fact"=>$pretty ) );
// END: Citation Master

%end:%

%label:continue%
...

The Parser Table will display the following when evaluating the %tngversion conditional

label tag

%label:xxx% requires a label as an argument, and is used for the goto destination on the %fileexists: or %tngversion conditional tags.

goto tag

%goto:label% requires a label as an argument, and is used skip over sections of code when using the %textexists: or %tngversion conditional tags to resolve conflicts between mods.

New Flags

Mod Manager 12 has new one-character flags that must be placed immediately after the first colon in certain Mod Manager tags:

• optional
• provisional
• protected

Optional flag

In previous versions of the Mod Manager, the optional flag (@) could be used on %copyfile or %copyfile2 tags, and now can be used on %target tags.

@ - optional. MM will bypass missing components and install the mod without them.

It can be added to %target: in lieu of placing a %fileoptional:% tag immediately below a %target tag.

//Skip this entire target section if the Spanish help file does not exist
%target:@languages/Spanish/places_help.php
%location:%
si no existen otros lugares.
%insert:after%
hay mucho más que decir..
%end:%
...
//Skip this entire target section if the Swedish help file does not exist
%target:@languages/Swedish/places_help.php
...

Provisional flag

^ - provisional.

This flag is useful in mods that create a directory (using the new %mkdir tag), and then uses %copyfile2 tags copy files to that new directory.

• When Mod Manager analyzes the mod, this flag prevents Mod Manager from generating a 'Cannot Install' message that would otherwise be generated because the folder that will be installed is missing
• During installation, if the folder is still missing, the %copyfile2 commands will generate an error.

The provisional flag essentially asserts that a directory will exist when a %copyfile2 command is executed during installation of the mod.

This example, for the Textplus Charts mod, copies images used by a help file into a new folder below the English language folder:

//Copy a help file to the language folder
%copyfile2:textplus_charts_v12.0.0.14/textplus_help.php:languages/English/textplus_help.php
//Create a subfolder for image files
%mkdir:languages/English/textplus%
//Copy the image files to the new subfolder 
//Note the 'provisional' flag, the caret (^), that prevents the %copyfile2 commands from 
//generating an error when the mod is being analyzed before installation.
%copyfile2:^textplus_charts_v10.1.0.13/English/descend1.png:languages/English/textplus/descend1.png%
%copyfile2:^textplus_charts_v10.1.0.13/English/pedigree1.png:languages/English/textplus/descend1.png%
etc.

Protected flag

~ (the tilde) is used in %copyfile% commands to "protect" a file, that is, to prevent the Mod Manager from

1. Removing the file when uninstalling a mod, and from
2. Overwriting the file if it exists when a new version of the mod tries to install it.

The intent is to allow mods to share files, or to leave a file in place so settings in the file are preserved when a mod is uninstalled and later reinstalled (for example, for an upgrade).

Note: if you use the protected flag to preserve settings that control a mod's execution and you want to add new options, you will need to add a %note: in the new version cfg file instructing users to rename the existing settings file before installing the new mod that adds new processing options.

Sharing Files

Before the Mod Manager implemented shared files, it was very difficult for mods to share functionality; such as when otherwise-independent mods want to

• Install the same form fields in a web page,
• Install identical form fields in different pages,
• Share Javascript functions that, say, open a Wiki page or toggle the display of parts of a web page,
• Share PHP include files that define a TNG menu (such as an Admin program tab menu) that is not defined in a central TNG Include file,
• Share a stylesheet (so that each mod doesn't add identical rules to genstyle.css),
• Share a PHP Include file that implements functionality that both mods need, or
• Install a PHP program that code from each mod would link to.

Example 1:
Let's say that several mods want to use a Wiki icon as a link to a mod's Wiki page. Before TNGv12, each mod would have to define a uniquely-named copy of the icon and install its own copy, resulting in multiple copies of identical files. But with the Protected flag, each mod can

• Put a copy of the icon file in its mod subfolder, without changing the filename, and
• Add a tilde to the %copyfile command that installs the icon file:
  %copyfile:~mymodname_v12.0.0.1/sharedwikilogo.gif:img/sharedwikilogo.gif%

No matter how many mods contain the shared file, and no matter how many times they are installed, there will be just one copy of the file in the TNG img folder.

Example 2:
Without going into details, let's say that a programmer needs for several mods to share a PHP Include file and a Javascript file. To accomplish this without having to copy both files to each mods's subfolder, the programmer could

• Put both files into a mods subfolder that will be shared by the mods. Let's call the shared folder RR-shared_place_formatting_code_v12.0.0.1.
• Zip that subfolder into each mod's distribution file, and
• in each mod, use these two commands to install the two files:

%copyfile:~RR-shared_place_formatting_code_v12.0.0.1/rrplacefix.php%

%copyfile:~RR-shared_place_formatting_code_v12.0.0.1/rrplacefix.js:js/rrplacefix.js

When each mod is moved to the mods folder, it will overwrite the shared mods subfolder if that sub folder already exists. But then, when the mod is installed, mod manager will detect if the shared files are installed, and will install them only if it needs to.

With this method, not only do the shared files exist just once in the TNG production folders, they exist only once underneath the mods subfolder.

Preserving Settings

The Placename Format mod installs

• A configuration file in the TNG extensions folder,
• A program that reads, updates and saves the configuration information, and
• Other programs that use the configuration settings.

Now, presume that the configuration settings have been changed and need to be preserved through a TNG upgrade. Significantly, when the mod is uninstalled, the configuration file will be removed from its TNG folder, thus destroying the current settings.

Of course, there are other ways to get around this problem, but "protected files" provide a very simple solution. All that the mod programmer has to do is to add a tilde to the %copyfile% command that installs the configuration file. With the protection flag in place:

1. The configuration file will be installed the very first time the mod is installed,
2. When the mod is un-installed, the configuration file in the extensions folder will not be deleted, and
3. When the mod is re-installed, the configuration file in the extensions folder will not be overwritten.

Removing a Protected File

It is important to note that protected files will remain in their production folders after all mods that use them have been uninstalled, and even when the mods have been deleted from the site. Of course, as the "Preserving Settings" example suggested, it may be appropriate for such a file to remain in place until it is needed again. But, in most case, to remove a protected file, you'll need to delete the file manually.

If you do not know whether you have any leftover protected files, you could:

1. Uninstall all mods, and
2. Use a file and folder comparison utility such as WinMerge or BeyondCompare to compare your working TNG folders with a pristine full TNG distribution.

Files are in working folders but not in the distribution are likely to be either

• Protected files, or
• Files that were installed by mods that were deleted from the site before they were uninstalled. (This is an easy mistake to make.)

$modspath and $extspath

TNG version:

≥ 12.0.0

TNG v12 adds the capability to use $modspath and $extspath within the %description section of the mod. This allows the HTML code in the mod's %description block to invoke scripts that are stored the 'logical' mods and extensions folders even on sites where the TNG administrator has renamed those folders.

The following are examples on how to provide hyperlinks or action buttons that execute files from the mods or extensions folders:

• A highlighted hyperlink:

<p style="font-weight:bold; color:red; border:thin solid red;padding:.5em;">
This mod adds several fields to the Branches table. <em>After Installation</em>, 
<a href="extspath/branch_timestamps_dbsetup.php" target="_blank">Set up or Remove the new database fields</a>.
</p>

• A button in the Bot-Trap Mod

<input class="button space" type="button" style="color:green;font-weight:bold" value="Run Checks" onclick="window.open('$modspath/bot-trap_v12005/bt_check.php','_blank');" /><br /><br />

• A button in the Cousins mod

<input class="button space" type="button" style="color:red;font-weight:bold" value="Delete the tables" onclick="window.open('$modspath/cousins_12.0.0.3/delete_table.php','_blank');" /><br />

This new capability allows the script to be run whether the mod is installed or not. This new capability might be handy to create or update needed tables. Of course the executed script might need to be updated to run from the mods/subfolder instead of the TNG root folder.

TNG version:

≥ 11.0.2

The $modspath and $extspath can be specified in the %target, %newfile and %copyfile2 in TNG v11.0l2 and after.

Error Detection

The Mod Manager now include better error detection and will return new error messages for

• invalid actions
• no access
• does not change anything
• folder not found

Invalid Actions

Invalid actions like using %insert:replace:% now returns Action Tag invalid error message

No Access

The Mod Manager now returns Unable to install this mod. Mod updates are required. Parameter line shows no access if the mod does not contain write access.

• Mod manager needs access to write to mods that provide parameters. Mods with Parameters require that the mod cfg file be written back out by the Mod Manager and now return an error message if the mod cfg file is read only.

• The error will also be returned if your mod .cfg file permission is 644 and the web server runs under a different user than the owner.

Does Not Change Anything

The Warning: Does not change anything in TNG! error status was added to show that mods using conditional processing did not modify any TNG files. In other words there are no files in the Affected List.

Mods folder not found

If the user renames the mods folder without updating the TNG Admin > Setup > General Settings > Paths and Folders, the Mod Manager will now return an error message.

Recommended Updates Tab

The new "Recommended Updates" tab in Mod Manager contains a utility program that updates the cust_text.php files to TNGv12 specifications.

The relevant specification change in TNGv12 is that mods should use a new target location search string,
//Mods should put their changes before this line, local changes should come after it.
to insert language strings into cust_text.php files. This change allows TNG users to override the text used in mods as well as add their own text strings after the new search string.

This utility was provided to update the cust_text.php as indicated in the TNGv12+ upgrade script NOTES section.

To run the upgrade utility:

1. Go to the "Recommended Updates" tab in Mod Manager.

   (If the "Recommended Updates" tab is not visible, go to the Mod Manager "Options" tab, select "Display Settings", and turn on the "Show Recommended Updates tab" option.)

2. Click the "Update" button in the "Recommended Updates" tab.

TNG mods that have been upgraded to use the new cust_text.php target location search string 'will not install on TNG sites whose cust_text.php files do not contain the new string. Those language locations will return a Bad Target