[Vtigercrm-developers] Roadmap and safety Vtiger & forks

Alan Bell alan.bell at libertus.co.uk
Fri May 13 13:19:10 GMT 2016



On 13/05/16 13:53, Błażej Pabiszczak wrote:
>
> @Alan
> It might prove to be a difficult task. At the moment barely any 
> changes we upload to YetiForce can be directly added to Vtiger. The 
> difference is that when we change anything in any module, we optimize 
> it, change the business philosophy, and adjust the engine right away. 
> What's most important, the majority of these changes is designed to 
> allow for even more changes in the nearest future.
> Additionally, the analysis of what we do might take you a while, check 
> what the monthly GitHub Pulse shows: "Excluding merges, 10 authors 
> have pushed 251 commits to developer and 253 commits to all branches. 
> On developer, 1,074 files have changed and there have been 40,048 
> additions and 18,621 deletions."
>
yes, that is a lot.
>
>
> The files we delete are no longer used by Vtiger, they are 4.x/5.x 
> version leftovers.
>
yeah, I figured they probably were OK to go, but hadn't traced that out, 
There is quite a lot of unused code in the system. Generally I like 
commits to have one purpose and that didn't seem to be related to 
improving the handling of information from $_REQUEST.
Can't say I am a fan of any of the stuff in the code that writes to the 
$_REQUEST object and in your commit uses AppRequest::set that seems like 
a bad thing to do. I understand why it does it, especially the 
webservices calls to get the line item data saved, but it doesn't seem 
to be the right approach.
It might be a better approach to have something in the request object 
that at the very beginning wipes $_REQUEST and repopulates it from 
cleanly parsed $_POST or $_GET data without cookies mucking things up. 
That way things could continue to read from $_REQUEST, but it has been 
pre-cleaned.

Alan.



More information about the vtigercrm-developers mailing list