New CK Finder license

In Fork CMS we use the CKFinder-plugin for CKEditor to allow people to upload and manage files through the editor. CKFinder isn't a open-source so a year ago Wijs and SumoCoders bought an OEM-license.

A week ago we received a notification from the CKSource that our OEM license would expire in a few weeks. So we had to renew the license. Figure8, Wijs and Sumocoders were so kind to sponsor the license for this year.

We thought the licence would be extended in time after we renew it, but it seems that this isn't possible. So there is a new license-key that should be used from now on.

So what happens to older installs? Well, as long as you don't upgrade the CKFinder-plugin it won't be a problem and you (or your clients) won't notice anything. If you upgrade you should alter the license key, this can be done through the backend ind the Settings-tab.

We would like to thank Figure8, Wijs and SumoCoders for sponsoring the OEM license.

Read More

Changing the license

To increase world-wide community support, we've decided to adopt the permissive and better-known free software MIT license, which states that:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Read More

The future of Fork CMS

  • Written by Tijs Verkoyen on Thursday 13 September 2012
  • 1464 comments

As some of you may have noticed, the latest releases didn't contain large improvements. So some of you may think Fork CMS is dying. Not at all! Fork CMS is very alive and kicking and we are preparing major changes.

Fork CMS uses the open source Spoon Library. While Spoon Library is great, it adds an additional learning-curve for most new contributors. The development on Spoon Library has stagnated and will be discontinued in the future. Therefore, we have decided to move to Symfony. We've picked Symfony for several reasons: it has a large community, great documentation and large codebase with a lot of existing functionality.

A second reason for moving to Symfony is that we want to concentrate on stuff that makes Fork CMS kick ass, and not the basic handling of URL's, a custom template-engine, ... So by moving to Symfony we think we will have more time to concentrate on new features that improves UI, usability, extra modules, ... .

A third reason is the large community of enthusiastic developers behind Symfony. We believe that by moving to Symfony it will be easier to find people with Symfony knowledge that are willing to contribute to Fork. In time we hope that Fork can contribute to Symfony as well.

How?

Moving to another framework is a major change and we can't accomplish this in a few days. So we are going to do it step by step. By replacing parts of Spoon Library by their equivalent Symfony component, we think we can move piece by piece, without halting the development of Fork CMS for several months.

Each change will be developed in a seperate branch and added as a pull-request on the master-branch when ready. So feel free to follow the development, add comments, add tips, ... on Github.

What does this mean for you?

Most internal components can be replaced without too much hassle for existing modules. We will try to provide backward compatibility where possible. In the end though, we will probably end up breaking backward compatibility for several features to be fully compatible with the Symfony framework, but this is something that will be discussed when we are at that point.

Contribute?

If you like to contribute, let us know. We are looking for people with a decent level of knowledge in Symfony, people who have experience with migrating codebases between frameworks are welcome also. Actually, everyone is welcome to contribute, provide us with tips.

Read More