Build forms with the formbuilder module

Written by Dieter Vanden Eynde on Monday 29 November 2010
23 comments

Building forms is one of those things most developers don't like to do. It's a repetitive monkey job that provides little to no satisfaction. So we created a module that allows anyone to create forms via Fork CMS. No longer do developers have to toil away at forms.

The module allows anyone to create his own custom form and link it to a page on their website, without the interference of a developer.

Options include changing the default values from form fields, to validation with custom error messages. In other words, you're able to tune the form to your liking.

But what to do with the data sent through these custom forms? The interface of the formbuilder allows you to browse through all your sent forms. Optionally, the formbuilder can send you an email each time a new form is submitted (including the form data). If you ask nicely it might even give you an export of all data.

Here's a sneak peek:

Comments

Lester wrote 13 years ago

Nice!

Davy wrote 13 years ago

Will it be possible to set a custom post method, so we can send data straight to a CRM like Salesforce? We might want to add ID's as well then. Looking forward to it.

Jasper@idetec wrote 13 years ago

That might come in handy :) Thumbs up !

Dieter wrote 13 years ago

@Davy: The first version of this module will not contain the ability to set a form target. This topic needs some more exploring first.

Hyde wrote 13 years ago

i also think that some custom fields would be very useful. for example to use the form as a small "interface" for sending customers to ogone to pay for something trivial (such as, subscriptions, participation in events, etc. ) in that case an ogone id are needed and some sha1 calculations.

mlitn wrote 13 years ago

@Davy:

Good idea which we'll definately be looking into. IMO you shouldn't exactly be able to change the action (target) however:

- the data will not be retrieved by the CMS

- users will no longer be on your site and we'll have rely on the target to redirect them back

However, I feel it might be a good idea to send the form back to the website (formbuilder) itself and let the formbuilder make a call to an external source (like Salesforce) with the received data from the customer. What's your opinion about this?

@Hyde:

Although I really like your idea and you out-of-the-box-thinking here, I don't feel this should be part of the formbuilder for these 2 reasons:

- If we provide a wrapper for Ogone in the formbuilder, would we also have to provide one for Paypal, Docdata, ...?

- The calculation of the SHA-sign is somewhat tricky: it can be done in 3 different SHA-encodings (depending on what is picked in the Ogone backend), it can be the old or the new Ogone system (which determines what fields will have to be SHA-encoded and how), the fields have to have a specific name, there should be a call-back page for Ogone to handle whether or not a payment was successful, ...

It's too technical in my opinion to be enclosed in a general formbuilder.

Though you have a point: a basic shopping module might not be a bad idea ;)

Frederik Heyninck wrote 13 years ago

Will it be possible to split the form up in different steps?

When you have a large form (questionnaire) you can assign witch questions to show in step 1, after validating step 1 go to step 2 and so on.

Dieter wrote 13 years ago

@Frederik: A "process" form is too advanced for a general formbuilder. We are trying to create a module that's easy to use and requires little technical knowledge. In my opinion, a form with multiple steps is custom work because the validation will be to complex to generalize.

Toon wrote 13 years ago

I think you could also send data to a Google Spreadsheet. There's an API for that, if I'm not mistaken.

That would be an ideal solution for things like basic event registration, membership (renewal) forms, etc. The functionality present in Google Docs could really leverage the data gathered.

Of course, with this kind of thing, you'll want to prevent people from gathering sensitive (credit card) data via simple forms. No matter what DB it's stored in.

Bram Vanderhaeghe wrote 13 years ago

@all

There's a lot of good idea's here. The question is: should we implement all this features in this 1 module?

The purpose of the formbuilder-module is: provide an interface to web managers, so they can create (basic) forms themselves.

The data is stored in the CMS's database (and can be send to an e-mail address as a kind of notifier).

My opinion: if it's useful to send to data to an external database or storage, it should be an second module handling that. 2 specialized small modules are better than 1 big cumbersome one.

Michael Mattan wrote 13 years ago

Looks great!!

Where can I download this module?

Peter Briers wrote 13 years ago

Looking VERY good. You have any idea when the new modules will be released?

You are slowly convincing me to shut down development for my own CMS, and start working on modules for this one. But I would like to see it mature a LITTLE bit more.

Like proposed a few times here, put it on github, so people can start sending 'pull request' to your project. That will speed up development a lot I think. (Or do you really want to keep the core an in-house production?)

Bram Vanderhaeghe wrote 13 years ago

@Peter

We'll put Fork CMS on Github soon.

Wolf wrote 13 years ago

@Peter Fork CMS is on Github: https://github.com/forkcms/forkcms

Bleh wrote 13 years ago

I seriously don't understand why you guys are reinventing the wheel all over again. Drupal has this stuff for ages. You have proven yourself to be good developers. Why won't you join effort on improving existing modules.

My 2 cents...

Bram Vanderhaeghe wrote 13 years ago

@Bleh

You are right: Drupal has almost every module one can imagine.

So why do we put so much energy in our own CMS?

Our main goal is to built the ultimate CMS for the people who actually work with the CMS (web managers, communication managers, marketeers, ...

Drupals' interface is not targeted at those users (and not at all usable for them).

There are more reasons... We'll write a blog post about it.

Drupaltronic wrote 13 years ago

"Drupals' interface is not targeted at those users (and not at all usable for them" .. ...mmm,.. have you tried Drupal7 (the ultimate CMS ) yet ??

Fork is a useless private effort doomed for.. obsolete : Join effort on improving DRUPAL !

Bram Vanderhaeghe wrote 13 years ago

@Drupaltronic

Yes, I tried Drupal 7. I consider myself as pretty web-savvy and still I couldn't figure out how certain things work.

More importantly: several of our clients are very happy with Fork CMS and told us they never want to go back to Drupal (this includes external developers!)

Btw: a bit of competition for Drupal can't be that bad... ;)

Drupaltronic wrote 13 years ago

Very true, but contributing at improving the UX and usability in Drupal would be even better, for the drupal community an ..Netlash ! After all, fork CMS 'Loaned' a lot from Drupal..

Tijs Verkoyen wrote 13 years ago

@Drupaltronic: How do you mean "loaned from Drupal"?

mlitn wrote 13 years ago

@Drupaltronic: saying that Drupal7 is "the ultimate CMS" and that Fork is a useless private effort is quite a bold statement and I wholeheartedly disagree with that opinion.

Yes: Drupal7 is a huge improvement over Drupal6.

Yes: Us (and others like us) all collaborating on Drupal could theoretically make it an even better CMS.

Both of these statements you made are valid. However...

Although Drupal definitely is a great CMS, we do not believe that there is no place for Fork CMS and that our efforts are doomed. Car-analogy: although BMW makes great cars, we do not believe that there is no place for Volvo, Lada or Lamborghini.

The competition actually is great for the webdevelopment scene. Imagine every webdeveloper in the whole wide world would contribute to and use Drupal for his/her projects. The would be no diversity + saying "no it can't be done" to the client would be very easy (=slow progression). Now we have to keep pushing the edges. If Drupal comes up with killer features, we cannot sit on our lazy asses and just do nothing, we have to make sure we fill the gap and go beyond Drupal. After that, same scenario but on Drupal's side.

I know the "example" presented above is a bit simplistic, but this actually is what it comes down to.

Several years ago, Drupal did not suffice for us. Drupal definitely is a good CMS, but it's not always the perfect solution for any webdevelopment job. We do not want to make websites that fulfill to the requirements of the CMS, we want to make websites that fulfill the client's desires. Ofcourse it's also possible to tweak Drupal in any way you desire, but that's not always how you want to approach a problem, that's inefficient. Sometimes a framework is better suited to tackle a certain project, sometimes a CMS is the best choice (sometimes Drupal with it's thousands of modules, sometimes a simple Wordpress blog, sometimes Joomla, ...), there's even times that just creating a simple HTML page with small parts of PHP code is the better approach for the job. It all depends on the project. Drupal was never an option for us because we do not want to force clients into the constraints of a CMS that we do not own and thus do not have the power to decide on the direction it's going, the priorities that are set, the development pace, the decisions that are made. To satisfy a broad audience of clients, we needed our own platform that provides the flexibility to handle a lot of different purposes and that can easily be turned right around without too much of a hassle for the next completely different job.

We do not believe in a "1 CMS to rule them all", but in an approach where the client comes first and the software suits his specific needs.

And backing up Tijs' comment: what did we "loan from Drupal"?

concerned user wrote 13 years ago

Should I be concerned that the last blog post and the last bug fix release is more than 3 months ago?

That the promised example templates cannot be found?

That the docs are still not up-to-date?

There seems to be a lack of community. Will Fork be able to survive without this or is it already dead?

U think there is too little activity on the blog to convince people to consider Fork as a trust-worthy alternative to Drupal or other mature CMS systems.

Tijs Verkoyen wrote 13 years ago

@Concerned user: it is a fact the blog isn't updated in while, but there is a lot of activity.

You can follow development on GitHub: https://github.com/forkcms/forkcms