CMS Made Simple Forums

I suggested in an earlier thread that there was a problem that was causing my system.log to have numerous entries relating to the deprecation of cccccc. The fault was actually my UDT using $Cgms incorrectly (but now corrected), but I've found that I still had system.log entries referring to '=& new' in a couple of Captcha files: As this only occurs if one is running PHP 5.3+, is it possible to have alternative 'include' files based on the version of PHP? In the short term, I have modified the 2 files in question, but any update of Captcha might overwrite my modification, whereas the inclusion of an 'include' selector might solve the problem while both 5.2 and 5.3 are being supported!

CMSMS does NOT SUPPORT E_DEPRECATED.

Please do some research before posting.  This topic has been asked and answered many times.

calguy1000 wrote: CMSMS does NOT SUPPORT E_DEPRECATED.

Please do some research before posting.  This topic has been asked and answered many times.

I did do some research before posting, on this occasion, and I know that CMSms doesn't support E_DEPRECATED in the core, but that doesn't mean to say that the core and module programmers should ignore the need to support newer versions of PHP, does it? You may have asserted your right to remove the option to use direct access to core Smarty to ensure an element of purity in the core (correctly, to my mind), but you cannot deny the need to support elements such as E_DEPRECATED at some stage; to ignore what might be core to a version of PHP is to ignore the very ground on which your software is based!

I had already noted that Captcha had a check to see what version of PHP was running and I see no reason for a similar check not to be included going forward. To maintain a dogmatic approach to what YOU support or don't support is to deny the people who support you. I have taken the action necessary for my own installation of CMSms, so it doesn't matter to me - but others might feel different.

We never said that we do not support PHP 5.3

And if you hade done your research sufficiently you would have seen that though we are making efforts to remove all the E_DEPRECATED and E_STRICT errors from the core we haven't explicitly tested for this yet, so therefore we don't support E_DEPRECATED or E_STRICT.  As well, because a vast majority of the modules were written and released while we supported PHP4, there is a high probability that they will output a bunch of E_DEPRECATED and/or E_STRICT warnings when somebody attempts to use them in a strict PHP 5.3 environment.  It is for these reasons that we do not support those options and request people to disable them.

However, this issue has nothing to do with support for PHP 5.3, it has EVERYTHING to do with the fact that the module was initially written for PHP 4, which we supported till not too long ago.

Now. your statement: "You may have asserted your right to remove the option to use direct access to core Smarty", is at the least confusing, and at the most just plain wrong.  Again, a lack of research and/or understanding of the issue.

Lastly, your proposed solution to put an alternate include statement into the code is the wrong solution.  The proper solution for supporting PHP 5.x (and ignoring PHP 4.x) and to stop these notices from being generated is a one character change.  Whenever the module developer gets to it.

The one-character change to each file is the action I took. I only brought up the issue on this board because I thought you were the most recent person to have had an input to the module (although the author appears to be Dick Ittmann), but I must have been in error. I appreciate all the work you do and have already done to provide a good solid system and I am certainly in awe of your knowledge and expertise (at my age, I think I am past my peak learning ability) - and I also understand that it must be frustrating to read comments/questions like mine when they seem ill-conceived. Thank you, anyway.