Mod Manager gotchas

From TNG_Wiki
Jump to: navigation, search
Ambox notice.png The following are items that require changes in TNG Mods with the new Mod Manager in TNG 10.1

Note that the use of word code in the following article refers to the text strings within the Mod Manager location and action directives and not necessarily to programming language code.

TNG 10.1.0


Tags must be terminated

You might have gotten away with not terminating the %description: tag previously, but with TNG 10.1 it will return a critical - %description tag not terminated and mark the status as Cannot Install

If you remove the URL to the TNG Wiki article for your mod from the %description: you must be careful to leave the % terminator in place. Otherwise you will get an error that prevents the mod from being installed.

Mod Manager tag not terminated.png

Tags must be on their own line

TNG 10.1 version of the Mod Manager requires that directives (or keywords) be on their own line.

Putting the code to be searched for on the same line as the location now produces a Cannot Install error - %location code section missing.

For example, in the Places Subject to Deletion mod the %location:% was not on its own line

%target:languages/English/places_help.php%
%location:%                <p>Your search criteria for this page will be remembered until you click the <strong>Reset</strong> button, which restores all default values and searches again.</p>
%end:%
%insert:after%
<p>Check "With no associated Events" to show only places that are not associated with any events and are candidates for deletion.  You may want to search for part of the location name before doing the search for locations that can be deleted because they have no associated events.</p>
%end:%
Mod Manager tag on own line.png

%replace used instead of %trimreplace

You cannot use %replace for a code fragment location. It will return a critical error code fragment not allowed here that prevents installation of the mod.

For example, the Living Color Mod had

// location 2 - add the 'living' flag to the database record fetch
%location:%
$query = "SELECT $people_table.ID, $people_table.personID, lastname, firstname, lnprefix, prefix, suffix, 
%end:%
%replace:%
//== next line modified by mod Living Color (location 1) ==//
$query = "SELECT $people_table.ID, $people_table.personID, lastname, firstname, lnprefix, prefix, suffix, $people_table.living,  $people_table.private,
%end:%

which needed to be changed to use %trimreplace:% for the code fragment replacement.

// location 2 - add the 'living' flag to the database record fetch
%location:%
$query = "SELECT $people_table.ID, $people_table.personID, lastname, firstname, lnprefix, prefix, suffix, 
%end:%
%trimreplace:%
//== next line modified by mod Living Color (location 1) ==//
$query  = "SELECT $people_table.ID, $people_table.personID, lastname,  firstname, lnprefix, prefix, suffix, $people_table.living,   $people_table.private,
%end:%
Mod Manager code fragment replace.png


%replace makes %location a fragment

If you use %replace: for a %location: that is a complete line and not a code fragment, you should not change the original line as part of the replacement function. If you do the Mod Lister might interpret it as an error and indicate code fragment not allowed here after the install.

For example,

%location:%
    tng_footer( $flags );
%end:%
%replace:%
if(! $_SESSION['nodraw']) 
    tng_footer( $flags );
$_SESSION['nodraw'] = false;
%end:%

it is best to code it as

%location:%
    tng_footer( $flags );
%end:%
%replace:%
if(! $_SESSION['nodraw']) 
    tng_footer( $flags );
$_SESSION['nodraw'] = false;
%end:%

Use of %trim directives

Use of %triminsert: or %trimreplace: instead of simply %insert: or %replace: may result in mods not being processed correctly.

For example, in the Persistent Bookmarks mod the %trimreplace:

%target:ajx_delete.php%
%location:%
        $logmsg = $admtext['deleted'] . ": {$admtext['user']} {$urow['username']}";
%end:%
%trimreplace:%
        $query = "DELETE FROM $bookmarks_table WHERE username = '{$urow['username']}'";
        mysql_query($query);

        $logmsg = $admtext['deleted'] . ": {$admtext['user']} {$urow['username']}";
%end:%

needed to be replaced with an %insert:before for the mod list to display the correct status

%target:ajx_delete.php%
%location:%
                $logmsg = $admtext['deleted'] . ": {$admtext['user']} {$urow['username']}";
%end:%
%insert:before%
                $query = "DELETE FROM $bookmarks_table WHERE username = '{$urow['username']}'";
                tng_query($query);

%end:%

Insert in same location

Two mods that insert code in the same location by using %triminsert:before or after may no longer work

One of the mods needs to be reworked to use %triminsert:after and the other %triminsert:before when both mods want to modify the same line of code.

Both mods may need to be changed

       For example, the Media - Census Plus International and the ShowTable mods both modify the showTable function in showmedialib.php
       

ShowTable previously used

%location:%
    echo showTable($imgrow,$medialinktext,$albumlinktext
%end:%
%triminsert:after%
,$mediadescription,$medianotes
%end:%

which needed to be changed to

%location:%
    $albumlinktext = getAlbumLinkText($mediaID);
    echo showTable($imgrow,$medialinktext,$albumlinktext
%end:%
%triminsert:after%
,$mediadescription,$medianotes
%end:%


Media - Census Plus International previously used

    Location 8 - line 523
%location:%
function showTable($imgrow, $medialinktext, $albumlinktext
%end:%
%triminsert:after%
, $cppersonID, $cptreeID
%end:%

which needed to be changed to

    Location 8 - line 511
%location:%
) {
    global $text, $rootpath, $usefolder, $showextended, $imagetypes, $size, $info;
%end:%
%triminsert:before%
, $cppersonID, $cptreeID
%end:%

to resolve the conflict where both mods add parameters to the showTable function

%location:%
function showTable($imgrow, $medialinktext, $albumlinktext
%end:%
%triminsert:after%
, $mediadescription, $medianotes
%end:%

Note that the conflict showed as Not Installed and not as a Bad Target, since both mods inserted code in the same line fragment.

Mod Manager not installed conflict.png

Inserted code must be unique

The code being inserted must be unique. One reason for this is that the code may be separated from the location used to position it by another mod activated subsequently so the location information cannot be used to remove the code. A way to guarantee the code is unique is to add a comment at either end of line or before and after identifying this insertion.

The Mod Manager checks whether the line being inserted exists in the code. The following are two variations of problems that can arise:

  • the insert code already exists
  • the insert code is identical in more than one location in the mod cfg file

Insert code already exists

If the Mod Manager finds the code to be insert any place within the target then it marks the code as already installed, even though the code is not installed at that specific location. For example, the following will result in the insert:after line being marked as installed even though that line is not immediately following the insertion point.

100 %location:%
101 .titlebox {
102 %end:%
103 %insert:after%
104         overflow:hidden;
105 %end:%

Since overflow:hidden; exists in the target css file, that location is marked as installed. This essentially makes insert useless when dealing with css target files.

To fix the above problem you need to code the mod directive as a replace, so that it only applies to a specific location in the target.

100 %location:%
101 .titlebox {
102 %end:%
103 %replace:%
104 .titlebox {
105         overflow:hidden;
106 %end:%

Insert code is identical in the cfg file

If you attempt to insert the same code segment in more than one location in the target, the second occurrence will be marked as installed but the target module will not be changed. For example, the second instance of the following insert code in the config file will result in the insert:after line being marked as installed and the insert not made since it was made previously for a different location in the code


100 %location:%    
101 }
102 
103 function buildGenNotes( $notearray, $entity, $eventlist ) {
104 %end:%        
105 %insert:before%
106 
107         /* START MOD: AccessRestriction mod v10.1.Beta */
108     }
109         /* END MOD: AccessRestriction mod v10.1.Beta */
110 
111 %end:%
112 
113 function checkXnote( $fact ) {
114 %end:%        
115 %insert:before%
116 
117         /* START MOD: AccessRestriction mod v10.1.Beta */
118     }
119         /* END MOD: AccessRestriction mod v10.1.Beta */
120 
121 %end:%

Since code to be inserted in the second location at lines 117-119 is identical to that in the first location at lines 7-9, the second location will be marked as installed and the code insertion will be bypassed.

To fix the above problem you need to code the comments in the code to be inserted so they are unique will only apply to a specific location in the target.

100 %location:%    
101 }
102 
103 function buildGenNotes( $notearray, $entity, $eventlist ) {
104 %end:%        
105 %insert:before%
106 
107         /* START MOD  buildNotes: AccessRestriction mod v10.1.Beta */
108     }
109         /* END MOD buildNotes: AccessRestriction mod v10.1.Beta */
110 
111 %end:%
112 
113 function checkXnote( $fact ) {
114 %end:%        
115 %insert:before%
116 
117         /* START MOD buildGenNotes: AccessRestriction mod v10.1.Beta */
118     }
119         /* END MOD buildGenNotes: AccessRestriction mod v10.1.Beta */
120 
121 %end:%

Use of Directive Keywords

The use of Mod Manager directive keywords like Description: in the mod %name: or %description: may result in unpredictable results.

Related Links

Mod Manager

Mod Manager Controls

For Mod Developers

Technical

Developer Tools

Example Mods