Sorry, btesec, I do not understand the "fix" after reading the posts again. I cannot find the lines you reference in any global source code search for "smartpartner" or a file by that name in my standard XOOPS installation.

XOOPS 2.4.4 VALIDATION

In order to validate for CSS level 2.1 and XHTML 1.0 Transitional, the following changes were made on one of my test sites:

1. xoops/themes/default/style.css

Lines 210, 215, 218 #xo-pagenav changed to .xo-pagenav

2. xoops/class/pagenav.php

Line 85 id="xo-pagenav" changed to class="xo-pagenav"

Re btesec's posting on January 8, 2010, regarding an issue with handling of html special characters like apostrophe in SmartFAQ, I noticed the same problem.

I upgraded one of my test sites from XOOPS 2.3.3 to 2.4.4 yesterday and found issues with html special characters (like apostrophe) in some modules, in particular SmartFAQ 1.08 (which still is the latest version as far as I could tell).

Was there any resolution to the problem? Do I need to try editing the code myself or was there already a fix?

Modules running under XOOPS 2.3.3, PHP 5.2.6, MySQL 5.0.32

The following legacy and new modules are running on my XOOPS 2.3.3 site. Legacy modules were edited for PHP5 compatibility and XHTML validation. New modules were edited for XHTML validation in most cases.

Legacy modules

Sections 1
Polls 1 (xoopspoll)
Weather 0.9 (vlweather)
Stockbox 0.1 (stockquotes)
Liaise 1.26
Popnupblog 1.33
Headlines 1 (xoopsheadline)

New modules

news 1.63
wflinks 1.06
smartfaq 1.08

My installation notes and suggestions follow the standard, supplied upgrade instructions below.

Upgrading from XOOPS 2.0.* above 2.0.14 and 2.2.* (using the full package)

1. Move the "upgrade" folder inside the "htdocs" folder (it's been kept out as it's not needed for full installs) on your local machine
2. Delete htdocs/mainfile.php, htdocs/install/, htdocs/cache/, htdocs/extras/, htdocs/template_c/, htdocs/themes/ and htdocs/uploads/ from the "htdocs" folder on your LOCAL machine
3. Upload the content of the htdocs folder on your LOCAL machine over your existing files on your server
4. For security considerations, you are encouraged to move directories xoops_lib (for XOOPS libraries) and xoops_data (for XOOPS data) out of document root, or even change the folder names.
5. Make the directory of xoops_data/ writable; Create and make the directories of xoops_data/caches/, xoops_data/caches/xoops_cache/, xoops_data/caches/smarty_cache/ and xoops_data/caches/smarty_compile/ writable.
6. Ensure the server can write to mainfile.php
7. Access <your.site.url>/upgrade/ with a browser, and follow the instructions
8. Follow the instructions to update your database
9. Write-protect mainfile.php again
10. Delete the upgrade folder from your server
11. Update the "system" module from the modules administration interface, other modules are recommended to update as well

Following the above instructions, Step #7 resulted in an error:

"This page cannot be displayed due to an internal error. You can provide the following information to the administrators of this site to help them solve the problem:

Error: Smarty error: the $compile_dir 'XOOPS_VAR_PATH/caches/smarty_compile' does not exist, or is not a directory."

Well ... on a hunch (having gone through the 2.0.18.2 to 2.3 and 2.3.2b to 2.3.3 upgrades on a PHP5 Test Site, I edited the mainfile.php file (which originally came from version 2.0.6). These lines were added, with values (in the same location as in the mainfile.dist.php file):

// For forward compatibility
// Physical path to the XOOPS library directory WITHOUT trailing slash
define("XOOPS_PATH", "");
// Physical path to the XOOPS datafiles (writable) directory WITHOUT trailing slash
define("XOOPS_VAR_PATH", "");
// Alias of XOOPS_PATH, for compatibility, temporary solution
define("XOOPS_TRUST_PATH", XOOPS_PATH);

After Step #11, go to the Template Set Manager and check for new System templates to generate -- there was 1 new one, making a total of 28.

Do Step #4, which also requires editing the mainfile.php file.

Also, when the tar.gz file is created under Mac OS X, watch out for all the "._" files, in particular in the directories:

xoops/modules/system/templates/
xoops/modules/system/templates/blocks/

as the Template Set Manager will show these Mac files as templates to generate. Remove them before updating System theme template files!

The structure and (some) content of the new xoops/themes/default/style.css may need to be edited into your custom theme file, e.g., themes/mytheme/style.css.

On a demo server, I upgraded XOOPS from 2.3.2b to 2.3.3. The 2.3.2b-to-2.3.3 upgrade package included the System module, which was updated; and the pm and profile modules (which remained inactive). Upgrade instructiions included in the release_notes file were followed.

Then I spent much more time than expected (the entire afternoon!) figuring out why the site looked different and why the header image was missing. Well, the upgrade package was missing some files in themes/default folder:

xo-banner_bg.png
xoops-logo.png
xoops-logo.psd

which were in the full release. But despite that location, the code was looking for the xoops-logo.png at the root level; so, I copied it there and the header looked okay at last.

Favicon use had changed to the themes/default/icons/favicon.png file, and so had overridden the favicon at the root level.

I also found no mention that the default theme had been dramatically changed. In particular, the typography was redesigned in the themes/default/style.css file, along with additional styling: the font sizing scheme in em's versus %'s, color scheme, and a large new section for the system_siteclosed page, which was part of the new themes/default/modules/suystem folder.

Validator Bugs

/xoops/class/pagenav.php

$ret .= '<div id="xo-pagenav">';

Changed to

$ret .= '<div class="xo-pagenav">';

xoops/themes/default/style.css

#xo-pagenav {

#xo-pagenav a {

#xo-pagenav a:hover {

Changed to

.xo-pagenav {

.xo-pagenav a {

.xo-pagenav a:hover {

Fixed Headlines 1 module delete bug which surfaced under PHP5 and XOOPS 2.3. Deletion of headline entries failed.

~/xoopsheadline/class/headline.php

function delete(&$headline)
{
// if (get_class($headline) != 'xoopsheadlineheadline') {
if (get_class($headline) != 'XoopsheadlineHeadline') {
return false;
}

Yes, installing the newer modules preserved the prior data. I backed up everything before doing so, just in case. My notes indicated:

SmartFAQ 1.08 can import FAQs from xoopsfaq 1.1. Cool!

News 1.63 installed over news 1.1, completely replacing the old module. The new version co-opted the prior database tables. Cool!

WFlinks 1.06 co-opts mylinks 1.1 database tables. Cool!

The PHP5 fix that zyspec mentioned is easy enough; however, I replaced news 1.1 with News 1.63, xoopsfaq 1.1 with SmartFAQ 1.08, and mylinks1.1 with WF-Links 1.06 for my PHP5 XOOPS 2.3 test site.

Elsewhere I've posted some remarks about XHTML validation testing for some new and old modules which required the $HTTP_*_VARS fix also. On an old XOOPS 2.0.18.1 PHP4 site I've fixed some old modules for XHTML validation as well as preparation for moving to PHP5 with XOOPS 2.3.

Since Liaise (1.26) has no built-in word censoring (that is, no use of XOOPS' censorString or another similar function), I did a simple hack to Liaise's include/form_execute.php file for the textarea case. See below. Has anyone already developed a better way?

Liaise remains valuable (and viable with XOOPS 2.3), and one of my clients allows anonymous users to send forms. Lately there's been regular salacious submittals. Banning the offending IPs has limited value. Preventing submittals in the first place might be somewhat useful, although far from foolproof anyway.

case 'textarea':
// check for bad words using XOOPS function
$temp1 = $myts->stripSlashesGPC($ele[$ele_id]);
$temp2 = $myts->stripSlashesGPC($myts->censorString($ele[$ele_id]));
if( $temp1 == $temp2 ){
$msg[$ele_id] .= $myts->stripSlashesGPC($ele[$ele_id]);
}else{
$err[] = "Improper language (censored words).";
}