I have not installed Fork yet but was just first testing with the demo site. I quickly found a way to bring down the entire site. If one goes to the home page, then delete the following:
The search widget (top block) The item in the left block The item in the right block
...the whole site stops responding. Deleting any subset of those 3 doesn't crash the site, but if you do all 3 it does. This can't be right.
Thanks for your message. We will definitely take a look at this and fix it right away.
Hi, this problem is fixed in the new master 3.10 (= 4) which is under development and will soon be released.
Great to hear, thanks! So if I'm in the early eval stages of Fork, is 3.10 coming soon enough that I should just hold off and wait to eval that vs. 3.9.6?
Well, since Fork cannot be installed into a temporary subfolder (critical for testing), I've reached a hard stop and cannot proceed, test and therefore even consider Fork... which is frustrating as it was looking to be the most-promising of the 12 or so I'm evaluating for this project.
I saw the FAQ but really that doesn't cut it: I've never seen any other CMS that couldn't be installed into a subfolder, so considering that no one else has a problem with it it's rather ridiculous for Fork to enforce such an arbitrary (and problematic) restriction. You're really overlooking a big need... TESTING... and it's really not Fork's job to dictate to the web admin how s/he should lay out or utilize his/her domain.
I'm using Fork for over 4 years now and I have never had the need to use Fork in a subfolder. There is almost nobody who wants to do this.
It's also better to test your sites locally as close to the production environment as possible. Since most clients don't want their sites in a subfolder, it's a lot smarter to also test your local version without a subfolder. This will help you find bugs that could are related to the site itself, and not to the way you've set up your local install. We use vagrant for that, it's a really great way to mimic your server configuration on your local test environment.
We're sad to see you go, but good luck finding a CMS/framework that fulfils all your needs. If you still decide to try Fork, we'd be glad to help. You can reach the community even faster using our slack channel: https://fork-cms.herokuapp.com/
Wouter Fork Core team
At our company, we have created more then 80 websites in around 4 years with Fork CMS. Going from one-pagers to big international websites and large e-shops.
5 years ago I was also in the search of a CMS that could tackle all the problems on our road. I've started to create our own CMS, because there was none on the market to fit our needs. We figured things out, there had to be a split between backend and frontend! It had to have "dashboard", "pages", "modules", "settings" tabs with each its own modules. I started programming it, but then suddenly I heard that Fork CMS was open sourcing. Didn't know anything about it, so I looked at the source code and said to myself "damn, that is exactly the structure that we were meant to program". So I stopped creating my own and helped Fork CMS become bigger and bigger with a very active community (you should definitely check out Slack as @woutersioen mentioned).
"damn, can't be installed in subfolder", was also my first impression. You don't have to take that so literally, anything has a workaround. We have worked in complicated server structures and this is never a problem.
- You can point your server document root to that subfolder
- You can do lots of things with symlinks you know!?
- We use capistrano te deploy our websites automatically (to subfolders on the server, and then use symlinks to the right path)
There is no CMS on the market that is so obvious "the best way of handling things".
Greetings, Jeroen Desloovere Github Moderator at Fork CMS
I appreciate everyone trying to help. I assure you I'm not trolling. I get that you want to try and test as similar to your real environment as possible, however:
1) In my case, doing precisely that means testing on my actual shared host. I am just a hobbyist... I don't have a cloned local software environment equivalent to my web host
2) Again, none of the other CMSes I've ever dabbled with have had this restriction. So it's not a problem for anyone else, who also certainly would advise to keep things the same for testing... BUT DON'T ARTIFICIALLY RESTRICT AND FORCE YOU.
For me, "testing" is making some test databases on my webhost, and setting up a test/beta/etc subdir off the domain to kick the tires. That way I'm using the resources available to me for a server while testing FOR REAL how the software works with the exact software and versions that it would should I deploy it for real/production. The current version of the website is untouched, and no one knows about the "beta" unless I give them the URL which has the subfolder.
www.mydomain.com/ already goes somewhere I don't want to mess with at the moment. However, testing was to be done in www.mydomain.com/fork/ (and others as I tested other candidate CMS solutions)
"There is almost nobody who wants to do this." I imagine there are more than you imagine. They just hit a brick wall with Fork and pass it over, probably not even bothering to give you the heads-up about it. I'll argue there's almost no one else doing the arbitrary restriction in installation that Fork is doing, and all these CMS packages would have the same testing needs that Fork has. It's not a problem for them, why is it a problem for Fork?
"It's also better to test your sites locally as close to the production environment as possible." That's exactly what I'm trying to do, except for the "locally" part. For exactness, I'm wanting to test on the software versions actually used by my webhost, which I have no control over.
Symlinks and other complicated workarounds aren't really suitable in my simple situation. My needs are modest, my setup uncomplicated. In fact, I came across "Fork" while searching for simple, lightweight CMSes (compared to Drupal, Wordpress, Joomla, etc... all of which I've dabbled with in the past).