Hi
I don’t know how many of you develop a product that needs to be distributed and customized for different companies but I have this problem solved for now with the inclusion of specific (internal) libraries that define functions with a different ID for each customer.
Through hooks to functions that in most cases are empty, I can manage the exceptions and extensions required while maintaining the standard product with its frequent updates.
So far so good but the number of customers is significantly increasing and the code is getting bigger and bigger with problems related to generation times and product dimensions, which for now has remained in a single version for all installations in production.
Duplicating the project every time is not an option as the customizations specifically concern actions that are triggered by events on some of the 300+ applications that make up the product and in this case it would become unthinkable to follow the evolution of the main product which is continues adding new features and modules. Furthermore, some of the installations do not require customization.
It would be nice to be able to manage projects derived from a main project but I believe this is unfortunately not possible in SC.
Have any of you faced similar problems?
Thanks in advance for the suggestions.
Giorgio.
I wish I had that too many customer problem.
True 
but it can also become a big problem if the development environment doesn’t help you.
I don’t disagree with you!!
Have you entertained the option of creating tables with specific SQL queries/commands and other settings and tie them into your customer account tables?
Then just call generic processes related to your customer information.
Thanks a lot for the tip.
Yes, in fact I use this method to manage the optional fields and display them, hide them or make them mandatory but to add more complicated validation conditions or processes to be activated following events, up to now I have followed the method I have described.
The alternative would be to store the code in the database tables too, but in this case there would no longer be the facilities derived from the use of SC. The same would be true in the case of external functions.
What do you think?
Ya I hear what you are saying. SC becomes so weird empty box in that case.
I guess it depends on what level of customization each client requires…
if you cant “re-use” some of the configurations and apply them to your clients as needed, then your method is just as valid.
First of all , congratulations for number of customers 
I don’t know which kind of customizations your customers need, but maybe you can use the same customization used by sugarcrm, or kind of.
Let’s say we want customize a validation event in the form sampleform.
In the OnValidate event of sampleform
$validate = true;
if ( fileexists( cusstomdir\sampleform_onvalidate.php) ) {
include_once( cusstomdir\sampleform_onvalidate.php );
$result = sampleform_onvalidate( $this );
if ( ! $result['ok'] ) {
sc_error_message( $result['errormessage'] );
$validate = false;
}
In a folder put all customization, if you want customize the event create a file and write inside a function with the same name that has one parameter, the form object.
Inside the function do whatever you want, just return a structure that tells if it’s ok or not, and the error message.
You have to create the file only for the customer that needs that customization, every customer can have a different customization, the form code has only the standard code.
If the file exists means there is a customizations, otherwise it’s standard.
the function sampleform_onvalidate has one parameter, in that object you have everything, I mean all fileds and also $this->Db I think is the ADOdb connection to database so you can make query on the db if you need it. If you make a print_r( $this ) you’ll see what there is inside.
The “problem” is that you have to use the translated code of SC, in the custom function, so you cannot use the SC macro.
So you cannot use {myfield} but $this->myfield, and so on.
It’s just an idea , I don’t know if can fit your needs.
Ciao
Vincenzo
Thanks Vincenzo
I will investigate this modality.
Using SC macros is very convenient but this seems like a good compromise.
Giorgio
This is really an interesting system architecture issue as much as it’s a code issue. Clearly you’re headed for a crisis doing what you’re doing, so you may have to undertake a major effort to refactor, with all the risk and hassle and cost involved with that process. The alternative is an eventual meltdown because you now have too many clients.
I have a 14-year-old Software as a Service product that was originally written in php with very few libraries, like jQuery. There are approximately 250 clients, and it appeared to scale nicely, although it’s non-responsive and therefore obsolete and we’re rewriting it. Obviously, the old version is not ScriptCase, (and neither is the new version because SC is not there yet in terms of responsive websites IMO) but the principle is the same. The structure is that each client has a basic shell that calls the symlinked common code for each module in the system. If they need a SMALL modification, it can be done in this code. Mostly this consists of non-functional, small display differences, like adding social media icons to an otherwise inaccessible area below the menu. There are a limited number of things that we will do in these kinds of modifications.
If they need something that other clients could use, then we rewrite the code so we can set a configuration flag. For example this software is for membership organizations, providing a public-facing website, a members-only website, and admin screens for those with specific admin rights for the newsletter editor, membership chairperson, treasurer, and so forth. Since membership is so important, it has many flags. As an example, some organization memberships expire in 365 days, while others expire on the same date for all members. That affects many parts of the system. So we control as many things as possible with settings. We have to make a decision when someone asks for a feature, whether it would benefit at least some other clients, and if so, we’ll add it to the next version to make our clients feel good about getting additional features. Sometimes we have to say no, that’s really a dumb idea and if we did that we’d get a huge number of complaints from everyone else.
However, the third category is something that is specific to one client. No one else is likely to use this feature. So we undertake this as a custom job after quoting a price. This totally custom code is controlled with tables named with a cstm_ prefix rather than an existing module prefix, and the code is similarly labeled. Then, because the menu is controlled through a table, we insert a record for the new function in the menu, and the client uses their regular menu manipulation software to move it where they want it and rename it as desired.
One more background item, and then I’ll (finally) come to the point. Before purchasing this particular company, my company wrote a similar product and we used SC for the many data-driven screens in the system. But in that case, we really needed a highly responsive front end, and so we used WordPress for the public-facing website, and had a menu to link to the members-only (and admin) parts, which was entirely in SC.
So, my point is that I think if you refactor your software design and control the menu through a table, you should be able to write the custom part for a given client as an entirely separate, small application in SC. I think the biggest challenge would be coordinating the login security so you can move between the applications if they are behind the paywall. I haven’t looked into this–you can research it–but the worst case would be that you implement security yourself so you allow free movement between the two or more separate applications once logged in. This will allow you to keep the core system intact and free of these custom pieces, and will keep the custom pieces easy to control as separate applications entirely. Then you just need to connect the menus, which is each with table control.
I don’t envy you this task, but the sooner you do it, the better. We’re in a similar year-long process. You may want to write a new system entirely, and allow clients to choose which version they want to be on. You can move a few clients over to test it and gradually make it the only version you support. This will stop the slow-down of your current system, while disturbing few clients initially.
Hope that gives you something to think about, even though it’s not a SC-code-specific answer.
Paul