We do accept offers of help

Quote:

Appears to be a small issue in XoopsModules25x/publisher

Quote:

Not yet, just this change notification.

Quote:

Quote:

That sounds very useful. I'll give that some thought, and see what we could do to implement that.

There are several ways you might accomplish this, depending on the exact requirements.

Here is an example from XOOPS 2.5.9, where the image manager code sets up to use the fine-uploader javascript. To do this, we used javascript in a script tag in a Smarty template to initialize the library code, passing in all the required language constants. In the template we can use the language constants as normal -- Smarty will do the substitution in the script code just like it will in HTML.

See the code here, on GitHub:
https://github.com/geekwright/XoopsCore25/blob/master/htdocs/modules/system/templates/system_imagemanager2.tpl#L52

This is a quick overview of some new things that are introduced in XOOPS 2.5.9 that Theme Creators should know about.

Form Renderer

In XOOPS 2.5.9 we have added a XoopsFormRenderer class, and a XoopsFormRendererInterface interface. The XoopsFormRendererInterface defines the final stage of form rendering, allowing the elements to be tailored to better adapt to the theme. XOOPS 2.5.9 ships with two implementations, XoopsFormRendererLegacy which matches the traditional XOOPS form rendering, and XoopsFormRendererBootstrap3 which uses Bootstrap classes to declare the form elements.

By default, XOOPS 2.5.9 will use the Legacy renderer. A theme can choose to use the Bootstrap3 renderer by including a file named theme_autorun.php in its top directory, as is done in the xbootstrap theme, containing the following:



New Smarty variables added in XOOPS 2.5.9


$xoops_page contains a condensed version of the current page name. For example, forhttp://myurl/index.php, $xoops_page would be "index". Forhttp://myurl/modules/profile/edituser.php, $xoops_page would be "profile/edituser".

$xoops_startpage contains the module configured as the start page, or "system" if no module is selected.

A "rendered" key is now set by XoopForm assign() method

Some scripts use the assign() method as an alternative to the display() method. This method assigns the form details to a stem variable named with the form's name. This assignment is done with code that looks like this:

$form->assign($GLOBALS['xoopsTpl']);

This technique has often been done to give the theme more control over the display of the form. It requires the template to loop through the individual form elements, and decide how to display it. This level of control is good if you need it, but can be a nuisance if you just want to position the form inside the page, and you would prefer the system to handle the details.

As of XOOPS 2.5.9, when the program uses the $form->assign() method, an additional stem variable, 'rendered', will be available. Instead of iterating over the 'elements' portion to build the form from pieces, you can simply display 'rendered' to use the system provided rendering:




Compatibility Breaks

Changes needed to existing profile module override templates

In the profile module, the profile_userinfo.tpl template creates an entire form to provide an activate/deactivate user button. Unfortunately, this form should have a security token. You can see an example of this in the XOOPS 2.5.9 htdocs/modules/profile/templates/profile_userinfo.tpl file at line 54:



Without this change, the button will not work in XOOPS 2.5.9. We try to avoid this kind of compatibility break, but in this case it is necessary.

Schema.org linked data separated from the HTML -- very interesting stuff.

First, Chrome 56 is discontinued. Chrome 58 is current for all platforms. I cannot replicate the problem you reported using a current version of Chrome. I recall seeing a notice in the past that came from a "post" (rather than "get") method search box, but that no longer seems to be an issue. Perhaps that was one of the numerous issues fixed since version 56.

Second, the change you suggest does not improve the security/risk potential in any way. The field still exists, and is still is being transported the same way.

There is an example in xswatch in XOOPS 2.5.9 that you could adapt to what you need:
https://github.com/XOOPS/XoopsCore25/blob/master/htdocs/themes/xswatch/tpl/nav-menu.tpl#L16

That constant is only used during the install.

After that, you can change it to anything you want in the profile module administration. Just edit the category and change the title.