Wow.  The TestFest forum thread is getting plenty of responses, which is great.  Thanks to those of you who have volunteered so far!

There was a great post to the forum thread by the user wichard, which I’d like to point out:

“No point in complaining about QA afterward if you don’t make an effort in participating upfront.”

Angel gave this post an upvote, which I happen to agree and give it a +1 as well.

Thanks Angel & wichard!

For those of you who aren’t familiar with what TestFest is, check out the forum thread.  If you ever wanted to get involved with the Sugar Community, the time is now

Interested in making the Sugar 5.5 Release the best ever?  Sign up to volunteer for TestFest!

What is TestFest?

A collection of end-users, developers, and SugarCRM employees who work closely together to validate new features and bug fixes in Sugar components that are important to their business.

When is TestFest?

TestFest is tentatively planned within two (2) weeks after the release of SugarCRM 5.5 Beta 2. Beta 2 should be released in the first week of September 2009. I will be in contact with you (the volunteer) as the dates begin to solidify.

Why TestFest?

Users, developers, and partners like YOU have made it clear to us that you want quality to be paramount. We have stepped up our internal testing, revamped the release process, and now are looking for your help to make SugarCRM 5.5 the best it can possibly be.

How does TestFest work?

I will be will be the main point of contact and coordination. I will ensure that various volunteers are not duplicating work while testing and ensure that objectives to cover various tests cases are executed.

You (the tester) will test various features/bug fixes in a particular component of Sugar. Additionally you will be testing on your platform and testing functionality that is critical to your business. Bugs will be submitted through the common channels. You will be given priority access to SugarCRM engineers if necessary when testing 5.5 Beta.

The best way to help *right now* is to help sign up volunteers by spreading the word and recruiting additional testers.

Please let me know if you are willing to help with TestFest.  You can comment here in the blog or in the forums.  I will contact you!

Thanks

It’s been almost two months now since PHP 5.3 has come on the scene, bringing not only many performance and stability improvements to the language, but also several new features that bring new capabilities to the language. The list of features added includes:

• Namespaces are probably one of the most sought after and debated features in PHP history, this enables you to namespace your variables, functions, classes, and constants to avoid naming collisions of having everything defined in the global scope.
• Closures are a feature that is popular in many functional languages as well as in Javascript, and allow you to define “throw-away” functions that are bound to a variable. The flexibility with this feature means you can pass functions as arguments to functions, defining these functions without having to worry about them needing to be in the global scope as well ( and in the process “throw” them away when they are no longer needed ).
• Late Static Binding give you more options when subclassing static methods and properties, enabling developers to resolve class references at run-time rather than compile-time.
• Circular garbage collection which will help memory usage in many complex objects ( we at Sugar are really excited about this ).
• Better Windows support, including VC9 builds which offer better performance than the standard VC6 built binaries ( big benefits to anyone deploying on Windows here ).
• Inclusion of the phar extension, which allows you to package an entire application inside an single file similar to JAR files in Java ( something else we are looking at here at Sugar ).

So with all these new features, it seems like moving to PHP 5.3 is a no brainer. The PHP project provides guides related to backwards incompatible changes and deprecated features for those upgrading from PHP 5.2, which cover most of things users upgrading their codebases to work with PHP 5.3 should look for as part of the migration. Here at Sugar we’re beginning internal testing on PHP 5.3 for future versions of SugarCRM, in the process making adjustments to the product as needed to ensure smooth sailing under the new version of PHP.

How many other developers have converted their applications to support PHP 5.3? Has it been easy, or have you had difficulty in readying you code? Sound off in the comments with your experiences.

Wouldn’t it be nice if there was an RFC spec and protocol for human communication? Perhaps we’d have no more miscommunications and we’d be more effective.

Ok that’s pretty geeky wishful thinking, but if you’re submitting bugs to SugarCRM – one of the best ways to do it, is by following this protocol:

For example:

Description: describe the problem

Requirements: any dependent requirements to reproduce the bug. Please include platform information

Steps:
1. Foo
2. Bar
3. Baz

Expected Result:
Hello World

Actual Result:
Fubar’d

Take a look at this excellent real world example.

Background

SugarCRM’s hosting objective is to maintain the integrity of the standard Sugar functionality when we upgrade a customer instance, and limit any negative impact our upgrade has on the customer’s modifications.

Prior to Sugar 5.2.0j (Patch J), Module Loader did not have the ability to detect whether the changes being uploaded are deemed “upgrade-safe”. For example, if a customer were to upload a module that modified standard Sugar functionality, an upgrade of the instance (new patch, new release) could impact those modifications, resulting in a production problem for the customer.

Modifications using the rest of the Developer Tools section of Admin are considered upgrade-safe. This includes Studio, Module Builder, and Workflow.

New Access Controls

Sugar 5.2.0j (Patch J) introduces a new Module Loader feature, the Module Scanner.  Module Scanner grants system administrators the control they need to determine the precise set of actions that they’re willing to offer in their hosting environment.  This feature will be available in all editions of Sugar, and will be put into action by the Sugar Open Cloud.  Anyone else who is hosting Sugar products will have the opportunity to take advantage of this feature as well.  This feature will also be available in Sugar 5.5.0 RC1 and later versions of Sugar.

The specific Module Loader restrictions for the Sugar Open Cloud are documented in the Sugar Knowledge Base.

Enable Package Scan

Scanning is disabled in default installations of Sugar, and can be enabled through a configuration setting.  This setting is added to config.php or config_override.php, and is not available to Administrator users to modify through the Sugar interface.

To enable Package Scan and its associated scans, add this setting to config.php or config_override.php:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘packageScan’] = true;

There are two categories of access controls now available:

1. File scanning
2. Module Loader actions

Enable File Scan

By enabling Package Scan, File Scan will be performed on all files in the package uploaded through Module Loader.  File Scan will be performed when a Sugar administrator attempts to install the package.

File Scan performs two types of checks:

1. File extension must be in the approved list of valid extension types
   1. The default list of valid extension types is detailed in Appendix A.
   2. Files do not contain function calls that are considered suspicious, based on a blacklist.
      1. Backticks (`) are never allowed by File Scan.
      2. The default blacklist of functions is detailed in Appendix B.

To disable File Scan, add the following configuration setting to config.php or config_override.php:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘disableFileScan’] = true;

To add more file extensions to the approved list of valid extension types, add the file extensions to the validExt array. The example below adds a .log file extension and .htaccess to the valid extension type list:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘validExt’] = array(‘log’, ‘htaccess’);

To add additional function calls to the black list, add the function calls to the blackList array.  The example below blocks the strlen() and strtolower() functions from being included in the package:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘blackList’] = array(‘strlen’, ‘strtolower’);

To override the black list and allow a specific function to be included in packages, add the function call to the  blackListExempt array.  The example below removes the restriction for the file_put_contents() function, allowing it to be included in the package:

$GLOBALS[‘sugar_config’][‘moduleInstaller’]['blackListExempt’] = array(‘file_put_contents’);

Disable Module Loader Actions

Certain Module Loader actions may be considered less desirable than others to a system administrator.  A system administrator may wish to allow some Module Loader actions, but disable specific actions that could impact the upgrade-safe integrity of the Sugar instance.

By default, all Module Loader actions are allowed.  Enabling Package Scan does not affect the Module Loader actions.

To disable specific Module Loader actions, add the action to the disableActions array.  The example below restricts the pre_execute and post_execute actions:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘disableActions’] = array(‘pre_execute’, ‘post_execute’);

A list of all actions available in Module Loader is detailed in Appendix C.

Edit, 2009-08-27, 11:30am:  An additional configuration parameter is also now available in Sugar 5.2.0j.

$GLOBALS['sugar_config']['disable_uw_upload'] = true;

This configuration parameter blocks the upload capabilities of the Upgrade Wizard, intended for hosting providers.  It behaves similarly to the use_common_ml_dir parameter for Module Loader.

Restricted Copy

To ensure upgrade-safe customizations, it is necessary for system administrators to restrict the copy action to prevent modifying the existing Sugar source code files.  New files may be added anywhere (to allow new modules to be added), but any core Sugar source code file may not be overwritten.  This is enabled by default when you enable Package Scan.

To disable Restricted Copy, use this configuration setting:

$GLOBALS[‘sugar_config’][‘moduleInstaller’][‘disableRestrictedCopy’] = true;

Appendix A – Default Valid File Extensions

1. png
2. gif
3. jpg
4. css
5. js
6. php
7. txt
8. html
9. htm
10. 10.  tpl
11. 11.  md5
12. 12.  pdf

Appendix B – Default Blacklist of Functions

1. eval
2. exec
3. system
4. shell_exec
5. passthru
6. chgrp
7. chmod
8. chown
9. file_put_contents
10. file
11. fileatime
12. filectime
13. filegroup
14. fileinode
15. filemtime
16. fileowner
17. fileperms
18. fopen
19. is_executable
20. is_writable
21. is_writeable
22. lchgrp
23. lchown
24. linkinfo
25. lstat
26. mkdir
27. parse_ini_file
28. rmdir
29. stat
30. tempnam
31. touch
32. ulink
33. getimagesize
34. copy
35. link
36. rename
37. symlink
38. move_uploaded_file
39. chdir
40. chroot
41. sugar_chown
42. sugar_fopen
43. sugar_mkdir
44. sugar_file_put_contents
45. sugar_chgrp
46. sugar_chmod
47. sugar_touch

Appendix C – Module Loader Actions

1. pre_execute – Called before a package is installed
2. install_mkdirs – Creates directories
3. install_copy – Copies files or directories
4. install_images – Install images into the custom directory
5. install_menus – Installs menus to a specific page or the entire Sugar application
6. install_userpage – Adds a section to the User page
7. install_dashlets – Installs dashlets into the Sugar application
8. install_administration – Installs an administration section into the Admin page
9. install_connectors – Installs Sugar Cloud Connectors
10. install_vardefs – Modifies existing vardefs
11. install_layoutdefs – Modifies existing layouts
12. install_layoutfields – Adds custom fields
13. install_relationships – Adds relationships
14. install_languages – Installs language files
15. install_logichooks – Installs a new logic hook
16. post_execute – Called after a package is installed

CNN posted a story yesterday talking about how web developers around the world are making their voices heard in their distain for Internet Explorer 6 in relation to the current state of the web. They talk about how supporting it is holding back the web, keeping them from adding cool features and enhancing user experience in web applications. It’s definitely good to see that this discussion has gone “mainsteam”, since IE 6 is truly a dated browser, ladden with security holes and with poor support for web standards.

You’ll remember back this spring I wrote up a blog post about the future of Internet Explorer 6 as we move forward with developing the new Themes Framework in Sugar 5.5. We evaluated all the feedback we received, as well as looked at current browser trends both with Sugar and out in the world. In the end we decided to limit our out of the box browser support for IE 6 to one theme, aptly named ‘Sugar IE6′ ( it will be a clone of the existing Sugar theme ). It will be automatically chosen when a user is using IE 6 as their browser so they have an acceptable user experience going forward. In the process, this enables us to optimize the user experience in all of our other themes, many of which have been redesigned to take advantage of the new features that modern browsers give us.

You can look forward to these changes in the upcoming Sugar 5.5 beta2 release. And in the meantime, take Microsoft’s advice and move on from Internet Explorer 6 if you haven’t done so already.