Symfony 2 is intensively using annotations. Also it detects custom classes by doing source code parsing. While Reflection API is used for getting annotations and that part works perfectly with encoded files, tokenizing of source files and searching for 'namespace' and 'class' keywords is also used. It's obvious that neither of the keywords can be found in the scripts after encoding. That's why running encoded Symfony 2 php scripts do not work out of the box.
We have developed a solution that lets run Symfony 2 encoded files but it requires modification of Symfony 2 engine and also needs minor changes in annotations. It's a simple fix but still it's a modification of the code. We are happy to share it if you need a quick solution, please feel free to read a full article
Although the fix tends to work we do not like it. We are working on a more elegant and universal method of encoding and running Symfony 2 encoded files that will not require any modifications of source code or engine. Please bear with us. We are not using Symfony in our work and we are not experts in it but we still appreciate importance of the fix as Symfony becomes more popular and our clients are using it in their projects.
Once the updated solution is ready we'll refresh this FAQ and also add a blog post about it.
By default Symfony 1.x excludes encoded files from autoloading. This happens because when Symfony 1.x is looking for classes and reading the contents of files it cannot find class definitions within encoded files. Encoded files do not contain any readable class or interface directives.
Your files may still work after encoding but only until you clear the cache in Symfony. A typical error you can get after encoding the files and clearing the cache is "Fatal error: Class '...' not found in..."
There is a way to fix that. You need to do that before encoding your files.
1) Create config_handles.yml file and put it in the project config folder (sf_root_dir/config)
3) Edit setup() in ProjectConfiguration.class.php file located in the the project config folder and add the following line before $this->enablePlugins() that is already there
4) Clear cache by running 'symfony cache:clear' in your project home
5) Run your unencoded project. If you already encoded the files, temporary restore to unencoded copies. Your project should run as usual.
6) Encode your files, clear cache and run your project again. There should be no error messages now. Do not forget to include the newly created cache/sourceguardian/classMapping.txt file when deploying your encoded project.
The sgsfAutoloadConfigHandler class creates an additional PHP 'class to file' mapping and stores it in cache/sourceguardian/classMapping.txt file. The file is automatically updated when you run unencoded files. When you finally encode the project, clear Symfony cache and its standard class mapping configuration cannot be used anymore, the sgsfAutoloadConfigHandler class starts using the previously saved class mapping from the classMapping.txt file.
This works similar to standard Symfony 1.x method of caching class names but in comparison to Symfony it is not cleared with other cache and uses relative file paths (Symfony uses absolute paths). As a result if you distribute the classMapping.txt mapping file along with your encoded files, they will run from the new location and a Symfony new cache can be correctly recreated.
Yes. There are some simple rules for successful encoding of WordPress plugins.
- Encode all PHP files, even if they are templates with mostly HTML.
- Do not encode the files that have comments that WordPress requires, such as plugin headers.
- Be sure to exclude any .svn, .git etc folders from the project.
- Turn off encoding for PHP4 in project settings.
- You still need to install an appropriate loader to the server in order to run protected files.
(Thanks to Sean Conklin for the comments about WordPress plugins encoding and testing)
If you are using phar and want to encode it or encode some of the files within your phar with SourceGuardian, there are two simple rules to follow:
1) Do not encode the entire phar file. Encode files you add to phar.
2) Do not encode a stub script if you use your own or use standard stub.