jerryvernon
Posts: 35
|
| Posted: 01/07/2015, 10:01 AM |
|
I have been having a problem with XXXXXX.php?ccsForm=FORM_NAME appearing when I create a search (CCS 4.3) with two listboxes, works ok on xampp on localhost,
XXXXXX.php?s_type_ok=1&s_location_ok=54
but upload to server 5.4 custom php
XXXXXX.php?ccsForm=FORM_NAME
When I changed the server php version settings in cpanel from native 5.4 to 4.4 the problem is removed and if I select php version 5.4 rather than native 5.4 the problem is also removed.
I hope this helps other who may be struggling with the same problem
Jerry Vernon PhD
Birmingham UK
Professional CCS Developer
|
 |
 |
pbarkley
Posts: 37
|
| Posted: 03/21/2015, 12:53 PM |
|
I ran into the exact same problem, but in my case it was because I deployed the Server2 application to another domain on the same physical box in a shared hosting environment (at MediaTemple). It had been running fine at localhost and running fine out on the server for more than a year, but when I moved it I got the exact problem described above.
I double checked but the version of php was identical in both domains, as was the php.ini file. I finally had to contact Yes support. Their solution was to delete the contents of the common.php file, leaving only any custom functions that you may have added at the bottom, and then regenerate the entire system. In fact that worked for me, leaving me to think that there is a bug, or let's say a not totally complete feature, in CCS that can't recover from changing the target deployment.
One more word to the wise. You're probably better off just extracting your custom code, if any, from common.php and setting it aside in a separate file while CCS regenerates common.php because it wound up at the top of my new file, and it picked up the closing php mark from my code, so nothing would run. Easy fix, and perhaps I should have removed that, but the next time I have to do something like this, and I'm afraid there may well be a next time, I think it's safer to just hold your custom code somewhere else while rebuilding. Of course then you'll have to manually fix common.php in your project folder (so it's there the next time you send the whole system up!), and then you'll have to FTP up the new common.php plus your changes, or else do ANOTHER generation, which is time consuming.
I'm hoping that this tip will save someone else the time that it takes to get an answer from tech support if you run into this problem. I realize since changing the php version worked for the original author, that that might work for others, but perhaps someone will benefit from this solution as well.
|
|
|
|
pbarkley
Posts: 37
|
| Posted: 02/26/2016, 1:40 PM |
|
After answering this in March 2015, I have run into this several times since, and I have a different solution, one that is much faster to implement, and that may work when the previous suggestion from CCS support to regenerate the common.php does not.
This solution has been posted elsewhere for other issues--I never would have figured this out on my own.
In my case when I was recently getting the ccsForm parameter added to every screen, causing an empty screen to appear, it was because of a tiny error in the common.php file at the very bottom at the closing ?> line. In my case, I had a blank line after this. I had to delete that blank line, leaving the last line as the one with the ?> on it. That may mean using a text editor that shows line numbers so you can see the blank line. Hopefully this will help someone else who runs into this problem, because if you get it while debugging some OTHER problem, you'll spend a week on it as I did. Good luck!
|
|
|
|
DataDoIT
|
| Posted: 02/28/2016, 6:19 AM |
|
If there is extra whitespace after the closing PHP tag (?>), then the
buffered output is sent. Thus, you're seeing CodeCharge submit the form
data (ccsForm=).
This is a PHP 'issue', if you want to call it that. Not a CodeCharge
issue. There are many debates on the innerwebs about the necessity of
the closing PHP tag at all. But in CodeCharge, since it is a templating
engine that loads in rendered HTML, the closing tags are required.
However, the question now becomes how the whitespace got there in the
first place. The ONLY way it gets in the Common.php file is from
altering that file directly. So I say this with over 12 years now of
CodeCharge experience and making the same mistakes ....
!!!! DO NOT ALTER THE COMMON.PHP FILE !!!!
In fact, don't alter ANY of the CodeCharge generated files. Common.php,
Templates.php, Functions.php, yourpage.php, etc. Put your stuff in your
own file (ie: Custom.php) and include it when and where needed. The
CodeCharge _events.php files give you the control and flexibility needed
for your application.
If things go haywire, you should be able at any time simply delete the
CodeCharge generated files, such as Common.php. CodeCharge will
regenerate the code and you're back in business. From the IDE in the
Project Explorer tab, right click Common Files and choose Generate Code.
|
|
|
|
eratech
Posts: 513
|
| Posted: 02/28/2016, 4:00 PM |
|
Quote DataDoIT:
I
!!!! DO NOT ALTER THE COMMON.PHP FILE !!!!
In fact, don't alter ANY of the CodeCharge generated files. Common.php,
Templates.php, Functions.php, yourpage.php, etc. Put your stuff in your
own file (ie: Custom.php) and include it when and where needed. The
CodeCharge _events.php files give you the control and flexibility needed
for your application.
If things go haywire, you should be able at any time simply delete the
CodeCharge generated files, such as Common.php. CodeCharge will
regenerate the code and you're back in business. From the IDE in the
Project Explorer tab, right click Common Files and choose Generate Code.
I can't agree with this enough - a lot of code-oriented developers (and I was like this originally too) like to get in and put their code in the CCS generated code, and that way leads to madness when updates don't work.
I use this exact method (mine are called 'Utility_Functions.php' and 'Utility_Filewriter.php' etc) to separate my code, and to group them near the end of the list.
Eric
_________________
CCS 3/4/5 ASP Classic, VB.NET, PHP
Melbourne, Victoria, Australia |
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 03/05/2016, 3:43 PM |
|
Guilty as charged.
I have an accountdisabled checkbox in user record and I have to see if it is ticked during login and I am also using two factor authentication which requires the use of a third field with a code in it that was emailled to the logerinerer.
I also lookup the timestamp of the last password change and if it has exceeded a certain date I set a session variable that calls a modal on hitting the first page which doesn't go away (set null) unless the password is changed. Too many ambiguities in how CC handles password hashing for me so that bit is in there too...
Then if the login code is successful I reset the code field.
All as part of CCLoginUser.
//CCLoginUser @0-361B7BC8
function CCLoginUser($login, $password, $logincode)
{
CCLogoutUser();
$now = time();
$password = hash("sha512",$password);
$db = new clsDBfm();
$SQL = "SELECT iduser, accessid, chgpwdtimestamp, firstlogin FROM users WHERE email=" . $db->ToSQL($login, ccsText) . " AND pword=" . $db->ToSQL($password, ccsText) . "AND logincode = '$logincode'" . "AND logincodeexpires > '$now'" . "AND active ='Y'";
$db->query($SQL);
$Result = $db->next_record();
if ($Result) {
CCSetSession("UserID", $db->f("iduser"));
CCSetSession("UserLogin", $login);
CCSetSession("GroupID", $db->f("accessid"));
CCSetSession("chgpwdtimestamp", $db->f("chgpwdtimestamp"));
CCSetSession("firstlogin", $db->f("firstlogin"));
CCSetSession("passwordexpires", $db->f("passwordexpires"));
CCSetSession("UserAddr", $_SERVER["REMOTE_ADDR"]);
$SQL = "UPDATE users SET logincode = 'xxxxxxx'" . "," . "logincodeexpires = '0'" . "WHERE iduser = " .CCGetSession("UserID");
$db->query($SQL);
}
return $Result;
}
//End CCLoginUser
_________________
Central Coast, NSW, Australia.
|
|
|
|
pbarkley
Posts: 37
|
| Posted: 03/13/2016, 9:26 PM |
|
Quote DataDoIT:
!!!! DO NOT ALTER THE COMMON.PHP FILE !!!!
Pshaw! Only wimps refuse to alter the common.php file! OK, just kidding. I will say that in the early days I was told by CCS tech support to save any changes I made to it, delete this file, and put back my changes, so it seemed perfectly reasonable to me, even if this answer to whatever the question was, is very similar to hardware guys telling you to burn down your computer and reinstall the OS and all your software on top of it. Kind of a general fix so you don't have to think about what the problem is, IMO. Oh you're having a problem, delete everything and start over. Well, yeah, that's one fix...
However, I have noticed that CCS now seems to have some smarts, or possibly annoying persistence depending on how you look at it. The last time I did this, I copied out all of my code that was at the bottom of the file, then deleted it, and when it regenerated all my code reappeared! So that said to me that CCS was storing a copy of it somewhere, which is not very reassuring when told to delete it. If I'm going to delete it, then I want it generated 100% new, not retrieved from some backup, or what's the point? Or is it smart enough now to regenerate everything except your own custom code?
I thought I must have been mistaken, so I repeated this process and all my code came back again.
However, in retrospect, I think DataDoIt is right, we shouldn't put anything in here. I have added special file name encryption code in an outside file and included it using one of the CCS events, and of course that worked fine, but I must admit it's handy and tempting to just put it in common.php.
In addition, I think this illustrates one of my frustrations with CCS. The guys who wrote this were definitely much more advanced than I am in various areas, and that's great...until something goes wrong. Then it's a lot more effort to troubleshoot than if you just wrote it yourself by hand. So, it's clearly a trade off. If everything goes well, it's a huge productivity booster, and it makes possible projects that just wouldn't be feasible otherwise. If anything goes wrong, you can get stuck for several days. Obviously those on this forum who are more advanced have fewer problems with the product and can fix any issues that arise much more quickly.
Hard to say where the sweet spot is, that is, when someone is competent enough in all the underlying technologies that this boosts productivity and almost never slows you down. However, I bought the product hoping that it would paper over my ignorance and just let me create systems. I don't think I could recommend it for someone else in that position, unless they've decided this looks like a good path and that after a few years of frustration using CCS they will finally be competent in not only CCS, but also in html, Javascript, php, MySQL server issues, etc.
|
|
|
|
MichaelMcDonald
Posts: 640
|
| Posted: 03/13/2016, 11:27 PM |
|
Yeah you got me thinkin....
I've always been concerned about common.php sitting in the root, there's a few functions I'd get out of there...
The conundrum is it would still involve either commenting out CCLoginUser or removing it altogether and now I am started on that also the $db credentials... where to start ? ..... where to stop ?
_________________
Central Coast, NSW, Australia.
|
|
|
|
rho
Posts: 85
|
| Posted: 03/14/2016, 1:38 AM |
|
Just my two cents: I usually work around editing the Common.php by putting all my general custom functions into an include page that a include in every page. If I want to add specific functionality to - for example - CCLoginUser() on a standard login page, I add additional Custom Code code (that contains my custom login code) to the On Click event of the login button (after the standard Login action that I keep in place), As the custom code is executed *after* the standard login, I can add any required functionality without touching the CCLoginUser() function. Of course, you have to check for proper login/password in this Custom Code before executing anything important (but you can copy that from the CCLoginUser() function).
This way I *never* have to add code to the Common.php 
Cheers, Rob.
|
|
|
|
DataDoIT
|
| Posted: 03/14/2016, 2:12 PM |
|
CCS will rebuild all functions in Common.php, as long as the existing
functions haven't been altered. At least that's the behavior I've
noticed. Those functions are built based on parameters in the
applicable XML of the .ccp and .ccs files.
Now I do put at the very bottom of Common.php this:
//To include custom functions file.
include(RelativePath . "/Custom.php");
?>
Again, at the very bottom just below the closing PHP tag.
In my Custom.php file, the beginning looks like:
<?php
# To use, place this at the end of Common.php:
# include(RelativePath . "/Custom.php");
/*------------------------------------------------------------------------------*/
## Custom Named Constants.
//Define the document root, or the folder on disk where the site runs
//from.
//We'll reference this throughout.
if (!defined('DOCUMENT_ROOT')) {
define('DOCUMENT_ROOT', dirname(__FILE__) . "/");
}
//Define the file upload temporary folder. This variable will be
//referenced in the file upload components. This is so we can deal with
//includes in subfolders.
if (!defined('TEMPORARY_FOLDER')) {
define('TEMPORARY_FOLDER', DOCUMENT_ROOT . "temp");
}
//Define the file upload folder. This variable will be referenced in
//the file upload components. This is so we can deal with includes in
//subfolders.
if (!defined('FILE_FOLDER')) {
define('FILE_FOLDER', DOCUMENT_ROOT . "content/");
}
/*------------------------------------------------------------------------------*/
.
.
.
I've included a nice little nugget for you guys when dealing with the
file upload components, and server and file locations.
|
|
|
|
DataDoIT
|
| Posted: 03/14/2016, 2:14 PM |
|
> Again, at the very bottom just below the closing PHP tag.
This should be just ABOVE the closing PHP tag.
|
|
|
|
|
