|Homepage||Robin Richmond's Genealogy Database|
|Mod Support||My Mod Support form or TNG Community Forums|
|Contact Developer||My Mod Support form|
|Min TNG V||10.1|
|Max TNG V||at least 11.1.2|
Modifies admin_genconfig.php, admin_updateconfig.php, English cust_text.php;
This is a utility mod that supports other mods, but is not required by them.
Purpose of the Mod
To support the use of Field Buttons by other mods, by installing
- Administrative setup form fields that implement a new TNG system variable, $tngconfig['rrfieldbuttonflags']], which allows Field Buttons types to be disabled.
This mod is needed only if a TNG site administrator,
- Installs at least one mod that defines Field Buttons in a form that is changed by that mod, and
- Wants to see Field Buttons in forms.
That is, if this mod has not been installed, Field Buttons that have been defined by various other mods will simply not appear. Thus, mods that install Field Buttons are not strictly dependent on the Field Buttons mod.
Field Buttons are hyperlinks formatted as buttons, that, with a single click, assign a particular value to an "attached" form field. There are four types of field buttons:
- X - Clear the field
- R - Reset/Reload the initial value; the value that was in place when the form was loaded.
- D - Default - Set the value to a default that was defined elsewhere, such as by a TNG system parameter or Mod Manager option.
- A - Set an 'All items' value. (At this writing, A buttons have been used only with "Results Per Page" fields.)
Note that it would be very rare for all four buttons to be attached to one form field. Only the applicable buttons should be attached to any given form field.
The four letters X, R, D, and A are used in documentation and in code to identify the field buttons, and they are the default on-screen labels for the buttons. But the labels are configurable through a translation string. In addition, a set of four fields in the Admin >> Setup >> General Settings >> Miscellaneous screen allow individual buttons to be suppressed in all forms on the TNG site.
Buttons are "attached" to a form field in that
- They follow it without intervening spaces, and the form field and its Field Buttons are wrapped by a tag that doesn't allow line breaks, and
- The buttons' field names are based on the fieldname of the field that they are attached to. The buttons' field names are essentially what causes them to modify their form field.
This screen clip illustrates 5 field buttons on 2 fields in the Admin>>Reports program that has been modified by the Admin_Reports_List mod.
- The search field has X and R buttons. There is no meaning in the search field to a default value (remember, the initial value is covered by the R button) or an "all items" value (which would just be an empty search field, and the X button serves the purpose of clearing the field.)is perhaps an empty field).
- The 'Results per page" has R, D, and A buttons.
- The R button restores the initial value - the value that was present when the form was loaded.
- The D button sets a default value, which, in this case, is the TNG system variable $maxsearchresults.
- And the A button sets a value that represents 'All Items'. That value is the word 'all' (or its translation).
- the X button is not needed when a field value is already empty,
- the R button is not needed when the current value is the initial value,
- the D button is not needed when current value is the default value, and
- the R button is not needed when the current value is the 'All Items' value.
When a button is not needed, it is shaded out, but still physically present on the screen.
We can tell just by looking a the screen clip above that is does not represent the initial state of a form, because we can see the R buttons. R buttons are always shaded out when the form is first loaded, because, by definition, the form field values when the form is loaded are the initial values. Here's what the same form might look like when first loaded, if the search value is empty, and the Results per page value is the site default value (in this case, 30).
The search field's R and X buttons are both shaded out, but still present (and barely visible). The 'Results per page' field's R and D buttons are also shaded out, and only its A button is visible.
If the user enters the search string "children", and click on the A button, we'll see this:
where the search field's X button is visible because the search field has a non-empty value, both R buttons are visible because both fields have changed, and the 'Results per page' field's D button is visible because the field's value is not the default of 30. Now, only the A button is shaded out.
Adding Field Buttons to Forms
- An ID, and
- A specific style class for each field button that will be attached to the form field (see examples below).
In addition, the program must:
The program can define the form field ID and/or classes either
- By modifying the HTML code directly, or
See details and examples in the Implementation
Compatibility With Other Mods
Dependencies on other Mods
This mod generates that can be used by the Show Mod Names mod, which is completely optional.
- Gedcom Import Mediatype is specifically designed to help make process of reassigning Media Collections easier. It allows you to specific a rarely used mediatype (say, Videos) as the default for new media items in a Gedcom Import. With new media items assigned to, say Videos, instead of Photos, it will be much easier to identify the new items that need to be reassigned. You still need this mod (or a more manual process), but Gedcom Import Mediatype helps to distinguish new media items from old ones.
- Admin Media Search also affects the Admin Media Search, and is more widely applicable than this mod.
- A working TNG installation.
- An installed current version of the Mod Manager.
- You should backup files listed in the panel on the right.
- Remove and delete previous version of this mod.
- Backup the files updated by this mod. They are listed in the panel at the upper right.
- Download the .zip file, Extract its .cfg file to the mods folder.
- Follow the normal automated installation for Mod Manager, as shown in the example Mod Manager - Installing Config Files.
In the event of a problem
Visualization of this Mod
Note the highlighted drop-down list. Only one entry is shown when the page is loaded; it has been expanded to list all of the predefined search choices. When "Headstones" was selected, the related search string was stored in the Search field in the form.
Note also that the collect "Photos" has been selected, since (without Gedcom Import Mediatype) most new Media Items are assigned to "Photos" (in the single-collection-folder environment that this mod was designed for).
When the user clicks on Search, the search results will list Photos that have the words "stone", OR "tomb", OR "grave", OR "burial" (etc) in the Media table description, path, notes, or bodytext fields. These results are (we hope) likely to yield Headstone photos, which belong in the Headstones collection. Upon seeing the results, the user can select the Photos that should be moved, and move several at once.
The search strings
The Admin Media Search form search the description, path, notes, and bodytext fields of a media item for one search string.
The following lines in the English and English-UTF8 versions of cust_test.php define a single string named 'presearchvalue' that contains multiple multi-valued, case-insensitive search strings.
$admtext['presearchvalue'] = "Census:census,ennumeration"; $admtext['presearchvalue'] .= "\nHeadstones:stone,tomb,grave,memorial,burial,cemetery,marker,crypt,resting place"; $admtext['presearchvalue'] .= "\nDocuments1:index,births,deaths,marriages,U.S.,records,registration cards"; $admtext['presearchvalue'] .= "\nDocuments2:death collection,marriage collection,certificate,license"; $admtext['presearchvalue'] .= "\nDocuments3:register,tax list,border crossings"; $admtext['presearchvalue'] .= "\nHistories1:bio,history,histories,memoir,notes,story,obit"; $admtext['presearchvalue'] .= "\nHistories2:article,letter,will ,will$,wills,probate";
Each line in the 'presearchvalue' string will be presented to the user as an option in the new the new drop-down box called "Preloaded Searched" on the Admininstration >> Media Search form. If you select "Headstones" from the drop-down box, the program will search for "stone" OR "tomb" OR "grave" (etc.).
To accomplish this, the modified code places the keyword "OR:" at the front of the multi-valued search string. The keyword "OR:" is not a search term, but it tells the program to treat the rest of the string as a series of comma-delimited search terms, each of which will satisfy the match. Thus, with this mod installed, not only can you select one of the predefined search terms, but you can also simply simply type OR: at the beginning of a comma-delimited search string of your own, and force the program to search for ANY of the search terms, rather than the search string as a whole.
- A normal search looks in five fields in the Media table - mediaID, description, path, notes, and bodytext fields. Preloaded searches, however, do not search the mediaID field.
- You might want to remove the term the term "stone" from the "Headstones" search string if you have a "Stone" family in your database. The same goes for the term "story" in the "Histories" search string.
- The term "will " in the "Histories2" search string contains a space so that names like "William" don't cause false matches.
- The dollar sign in the term "will$" in the "Histories2" search string represents the end of the target string, just like it does in regular expressions. Given that "will " has a space at the end, "will$" allows the search to match "John Brown's will", while not matching "William".
- The search terms "will " and "will$" will, however, match "Will Smith Death Certificate".
To modify the search strings, you should create entries at the bottom of your cust_text.php file that completely redefine $admtext['presearchvalue']. That is, you should start with a line such as
$admtext['presearchvalue'] = "Census:census";
followed by each additional search string, using the "assign and append" operator, ".=", and placing a colon after the search label (Census, Headstones, Documents1, Documents2, etc.).
This mod places its string definitions immediately after the standard cust_text.php string
//Put your own custom messages here, like this: //$text[messagename] = "This is the message";
rather than at the very beginning or very end of the file, so that, if you uninstall and reinstall the mod, your own 'presearchvalue' customization will still come after the mod's definition, and will thus be used by TNG.
Mod Change History
*** The newest version of the mod is at the top of this table ***
|Mod Version||TNG Version||Date||Note|
|10.1.0.4||10.1 - 11.1.2+||1 Dec 2017|| Removed the second line from the cust_text.php target location search string.
Also repositioned the Predefined Search field in the form layout table to be compatible with a new version of Admin Media Search.
|10.0.3.3||10.0.3 - 10.1.3||21 Feb 2016|| The predefined strings dropdown list now maintains its selection after search and page operations within a search.
I also tweaked some of the predefined searches. This mod now uses (and depends on) Show Mod Names v2+.
|10.0.3.2||10.0.3 - 10.1.2||01 Sep 2015||Added some search terms, and implemented special processing for "$" at the end of a search term to anchor that term to the end of a target string.|
|10.0.3.1||10.0.3 - 10.1.1||08 May 2015||Initial release.|
Sites using this mod
If you download and install this mod, please add your site to the table below.=
|Robin Richmond's Genealogy Database||Robin Richmond||Mod developer||10.1.0.4||11.1.2||English|