UPDATE:

Well, from what I've researched, this appears to be a PHP language bug that occurs on 64 bit servers. This explains why I suddenly started receiving this error after I moved on to a new server. Apparently, the error is with the PHP strtotime() function. From what I read, it appears that the smarty tag <{$smarty.now|date_format:"%Y"}> utilizes data from the strtotime() function, which causes this specific smarty tag to fail on 64 bit machines. I tried out the strtotime() function on my server, and it generates the error. Also, the result changes every time I refresh the page, which is consistent with the behavior in the themes.

They are working out (or have worked out) a fix for PHP 5 on 64 bit servers, but I don't know if they are doing the same for PHP 4 (apparently they haven't thus far). Thus, theme developers should be aware of this possible smarty tag problem, and maybe update their themes or provide some replacement code for people experiencing this date error.

It would be good to hear from some other XOOPS users, to confirm that others are having the same problem as me. This may become more of an issue as more web hosts update to 64 bit servers.

Here is a link to an old discussion about the PHP bug.

Dave

Any ideas on this date problem?
(The details are included within the original post above.)

Has anyone else noticed a similar date problem on their site?

More specifically, this date problem is occurring with several of the themes I've initially installed, such as 7Clean, 7dana-rose, and girlsclubII. However, geometric_red displays the date properly.

Again, the only difference in the actual themes is that geometric_red uses a javascript script to generate/display the "correct" date, but the other themes use the following smarty variable: <{$smarty.now|date_format:"%A, %B %e, %Y"}>, which generates the incorrect date and causes other odd behavior (such as the date continuously incrementing while browsing to other pages within the site).

I'm 99 percent sure there is nothing wrong with the actual themes, since the date has worked correctly on other XOOPS sites of mine. However, I don't know where else to look for the source of the problem. Could it be a problem with the latest version of XOOPS (2.0.16)? Could something be corrupted with the Smarty components of XOOPS? Could it be that the latest copies of Frameworks/Xoopseditors are causing some problem? Or could it be some kind of server problem?

Any direction with this would be very much appreciated.

Thanks,
Dave

Hi,

I've recently moved to a new server, and reinstalled my XOOPS site. For some reason, "some" of the themes (which display today's date) are displaying the date incorrectly. The date looks something like this:

Sunday, November 6, 116568

It gets even weirder. Anytime I browse to another page on the site, the date increments or changes to another date (with the same weird format).

Other themes display the date correctly, and there doesn't seem to be a date problem outside of the themes (such as with date/time stamps within the postings of various modules).

The only difference I noticed (regarding themes) is that the date is wrong when the theme uses a smarty date variable (such as:<{$smarty.now|date_format:"%A, %B %e, %Y"}>). The theme that displays the date correctly uses javascript to display today's date.

I've never had this problem with these same themes on my old site (which was on another server). The only differences other than a different server, is that I recently installed the latest versions of "Frameworks" and "Xoopseditors", and I've upgraded from 2.0.15 to 2.0.16. I even tried using an earlier version of Frameworks (which made no difference), even though I didn't think it would influence the themes in any way.

I don't think this is a server issue, since the dates display properly everywhere else. Does anyone have any idea what could be causing this problem?

Dave

Hi Jensclas,

Thank you for lessening my concerns.

Dave

Hi,

I just installed the full version of 2.0.15. The installation seemed to go ok, but I keep receiving error messages (in debug mode). These error messages are only occurring in the administration sections. I upgraded to 2.0.16, but the errors are still there. I never had this problem with my other installations of XOOPS on another server, including 2.0.15.

Here are a few of the error messages:

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 78

Notice: Only variables should be assigned by reference in file /class/xoopslists.php line 200

Notice: Only variables should be assigned by reference in file /kernel/module.php line 542

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 155

Notice: Only variables should be assigned by reference in file /kernel/tplset.php line 193

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 136

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 94

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 94

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 94

Notice: Only variables should be assigned by reference in file /modules/system/admin/preferences/main.php line 174

Does anyone have this same problem? Is there some way to fix this? If not, is it ok to leave it this way? The messages go away once I turn off debug mode.

Dave

Some shared hosting plans have very severe limitations on how many simultaneous database connections can be opened at any one time. Unfortunately, this is rarely ever mentioned when they are promoting their plans. They promote the plentiful drive space and bandwidth, which is very appealing if you have at least a moderate traffic site. However, increasing traffic means an increasing need for more available MySQL connections.

You may want to ask your hosting service about how many concurrent database connections they allow, and if they have an upgraded plan that allows more connections. Although, they my try to sell you on a semi-dedicated, dedicated, or virtual server option. Those are good options for many reasons, but they become more costly.

You may also consider moving to another shared hosting service that is more generous with their database connections. Hosting services do vary quite a bit regarding how my connections they will allow.

On the other hand (as others mentioned), using more of the caching features and upgrading to at least 2.0.14 my solve your problem (temporarily at least). Although, there still may come a point where your traffic becomes so heavy that you need to move to a dedicated or other option.

Dave

Hi Metropolis and everyone,

After I read your reply, I looked more closely at the default theme.html file, and more clearly understood the logic behind the bottom block feature (added to 2.0.14).

The left-center and right-center blocks will always be positioned below the center blocks, regardless of how you set the weights(at least through version 2.0.14). However, with the added bottom block positions, there is a way to position a set of left-center/right center blocks between the top and bottom center blocks, and have more left-center/right-center blocks at the bottom of the page too. This can be done just by using the top/bottom positions and weights in the blocks administration section of the system module.

Basically, the top left-center and top right-center blocks will always render below the top center blocks, and the bottom left-center and bottom right-center blocks will always render below the bottom center blocks. However, any bottom center blocks will be positioned below any top left-center and top right-center blocks, which basically gives you the ability to have top left-center and top right-center blocks positioned between the highest weighted top center block and lowest weighted bottom center block.

I'm probably not stating anything that many others have not already figured out, but it is just now making sense to me (especially after looking more closely at where the theme.html file renders the different block sections). As you said, it would be more flexible if there was one big outer loop that controlled all the center blocks. However, I think that 2.0.14 is a big improvement in positioning flexibility. Maybe future XOOPS versions will make the positioning even more flexible with the idea you suggested.

Dave

Hi Jensclass and Javelin,

I did search the posts, but didn't find anything that solved the problem. This is why I posted here for help.

I've seen some suggestions for modifying the theme.html, but that doesn't give much flexibility, especially if you are frequently adding and repositioning blocks quite a bit.

Ideally, we should be able to position the left-center and right-center blocks anywhere we want relative to the center blocks (and vice versa). However, it seems that the block weighting is only relevant to the section that the block resides in (sections = left, right, center, left-center, right-center, right, etc.) In other words, the weights applied to center blocks will only position those blocks relative to other center blocks, and the weights for left-center or right-center blocks only apply to those particular sections. The actual sections seem to be positioned according to the way the theme.html file is coded. I'm not sure if I'm 100 percent right about this, but that is how it seems to be.

I know that the 2.0.14 upgrade is supposed to allow more flexibility in positioning blocks, but I'm very vague on what this really means. I've not found a post, FAQ, or documentation that explains this in more depth.

Dave

Hi,

Anytime I set two blocks side by side (left center and right center), both blocks are pushed to the bottom of the page below all of the center blocks. XOOPS seems to ignore how I weight the position of those blocks, and always pushes them to the bottom below the center blocks.

Am I doing something wrong? I've seen other sites where the left center and right center blocks can be positioned anywhere relative to any center blocks on the page. I can't figure how to control this.

Any help would be appreciated.

Thanks,
Dave

Hi,

I will put my two cents in here. Honestly, I've not seen another open source CMS that comes close to the quality of XOOPS in terms of flexibility, user interface, intuitive administration, module selection, documentation, and community support.

Of course there is lots that can be improved and refined (as with any product), but I think that XOOPS is a very mature and dependable system when compared with other open source CMS systems. Also, I believe that the developers have done an incredible job bringing XOOPS to its current state of maturity and dependability, especially considering the relatively short length of time that XOOPS has been around.

In my opinion, XOOPS is going to be around a long time and it will eventually be recognized as the top open source CMS system in the industry. Once XOOPS gets further along on its roadmap, it will probably be a huge evolutionary step, just as Windows 95 was in comparison to Windows 3.1.

I also agree that providing positive feedback in these forums is very important. It not only generates enthusiasm for the developers who work so hard on this system, but it also attracts many organizations to take a chance on XOOPS. It may also result in more developers and others contributing to the project, which will accelerate its evolution. I would be willing to help out in some way. That is how much I love this system and want to see a long successful future for it!

Dave