I'm new to Drupal, but I want to create an add-on. The add-on requires some sort of multi-page form with advanced jQuery (I already looked at the jQuery module).
The add-on requires details of the current logged in user and will also communicate with an external database.
I've been looking at tutorials concerning Module creation etc. But they mostly cover creation of simple forms, where as what I want to create is more of a plugin.
Multi page forms are a total drag. Pro Drupal Development, has a very good section on this topic, and I highly recommend that book if you are doing any Drupal development.
Online I found the following article pretty useful too (though I ultimately went with my own system).
http://www.nicklewis.org/using-chaos-tools-form-wizard-build-multistep-forms-drupal-6
There's a decent example here:
http://thedrupalblog.com/creating-multipage-form-using-forms-api
To make the most out of this, you're going to want to get pretty friendly with the Form API:
http://drupal.org/node/204270
Sadly Drupal.org seems to be missing a Drupal 6.x explanation (though plenty exist for 5.x and 4.7 oddly enough).
Multi step forms are complex by nature, but there are some methods to make it easier. I recommend that you have a look at the multistep form tools offered by the Ctools module. This blog post by Nick Lewis explains how you can use it.
I think you should think twice before going with javascript/jQuery to create your forms. Javascript is a great way to improve the user interface, but it can be easily manipulated because it's client side technology. You shouldn't rely on javascript alone for things like input validation, temporary storage of form values and controlling the flow between different steps of the form.
I feel odd saying this, but I don't think you want to use the Drupal Forms API.
The Forms API provides a lot of security features (unique token, rebuilds form after submit to compare to ensure correct form is processed, etc.) and allows other modules to modify your forms, but I think a lot of those features will get in the way of your jEditable form. Multi-page forms are not that challenging using the Forms API, but jEditable elements will be.
Your module could simply add a menu item with a page callback function that puts together your jEditable form for you. That is about as close to the world of a 'normal PHP' script as Drupal will let you get.
Related
I have been creating a custom web application using mainly PHP with some Javascript. I have been curious about rebuilding the site using Drupal. I have only produced a 'minimum viable product' and it is functional but not nearly as professional looking or feature rich as it needs to be with using some tailor made modules.
It may be easier just to look at my site, but I will describe it below as well. http://www.localtolocal.ca
Visuals need improving but that is another discussion all together!
I previously felt that it needs to be a custom application but since I want to incorporate things like articles, video content and forums I was thinking using Drupal may be very helpful. What I have so far is the part that I was thinking needs to be written by myself.
I have mostly seen Drupal used for sites that are blog based, content providers or eCommerce focused. My site's main focus is user-provided data. A user creates an account and will either browse and write reviews, favorite pages etc. OR post data about their business or endeavor. A small business would input their contact info, information about themselves and what they provide and that creates a page to display the information on, like this:
http://localtolocal.ca/display_page.php?page_id=23
They are also able to create custom vouchers, add photos and of course update information they have previously input. I will eventually also have paid subscriptions meaning tiered user structure.
Are there Drupal modules out there that can accomplish this? I assume it would need a considerable amount of customization.
Can Drupal be used to create something as full featured as Yelp or a high profile social media site? Asking in terms of evolutionary potential.
Would that learning curve not even be worth it compared to flushing out my custom application?
You can surely use Drupal to create a user generated content driven site as described. True, the learning curve is steep and it'll take some getting used to, but once you get the hang of it, it'll be worth the effort imho. With Drupal you can develop a user-testable prototype of your application within days which is a really big win.
The site doesn't seem really complex, so main challenge will be defining the personas and testing that they have the correct permissions. In general I would suggest extending the user profile so they can submit information about their business, using the flag module to favorite pages and a separate content type for reviews (which you can publish direct and moderate later or the other way around).
I want users to be able to submit nodes and comments via AJAX. I also want to do some fairly extensive customization of the node and comment forms.
I've spent time looking through documentation and code examples for Drupal 7's Form API and Ajax framework, but I find it very complex. Therefore, I simply want to create my own form in HTML and use my own JavaScript code to submit it via Ajax. I'll also set up a specific URL for processing these Ajax requests, which will ultimately call node_save() or comment_save() when appropriate.
What are the downsides to doing it this way as opposed to going through the Form API and Ajax framework? I'm not creating modules for contribution to the community. Everything is just for my own site.
Technically, yes you can do this with no ill effects. There have been times where i have had to import data from feeds and have used node_save manually.
What you are missing out on is the flexibility that drupal offers. For example, want to add a new checkbox to the form to indicate a featured item? Now you have to manually update the form to add the field and update the submit handler to save the data. Had you used drupal's system it would of been auto-populated for you.
Further on flexibility, say for example, you decide you want to add a CAPTCHA field to your form. All you would have to do is enable the CAPTCHA module and specify the form you want it on and it would be done for you. There are a bunch of 3rd party modules that let you do things like this.
Drupals form system also lets you add more complicated items such as date selectors, or even managed file uploads, which can save you a lot of time once you are familiar with the API.
If your looking just to get the project done and not spend time learning something new, sure you can do it all manually. I can promise you any drupal developer that looks at your code in the future will have a very low opinion of your work. Depending on your situation this may or may not be important. But really the biggest thing you are missing out on is ease of maintenance and flexibility.
So just to recap:
pros:
it will work
quick and easy
comfortable
cons:
loss of flexibility
harder to maintain
inability to take advantage of drupals form widgets / helpers
inability to take advantage of 3rd party modules
shame from other developers
Lack of sleep from dirty feeling
eternal damnation
The usual argument would be about portability I guess, but if you're not going to be porting these modules to another Drupal site then I guess that falls down.
The same can be said for offering other modules the chance to alter your form based on some global/inherited setting, but again if you really don't want/need this functionality then it can't really be used as an argument against.
The one thing you will lose out on is the built in Cross-Site Request Forgery protection. As long as you're rolling your own version of that, though, you should be ok.
If you plan to use Drupal a lot I'd recommend getting used to the FAPI though...after a while it actually becomes a lot easier to use the FAPI than write out custom HTML.
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm trying to write out a list of key Drupal competencies, mainly so I can confirm what I know, don't know and don't know I don't know. (Thanks D. Rumsfeld for that quote!)
I think some of these are really broad, for instance there's quite a difference between making a functional theme and creating a theme with good SEO, load times and so on, but I'm hoping you could assume that a half decent web developer would look after that anyway.
Just interested to see what people here feel is also important. I've edited the suggestions so far into this list.
Languages
PHP
MYSQL
Query
Drupal Skills
Research and install modules to meet project requirements
Configure the basic modules and core settings to get a site running
Drush command line tool
Create a custom Theme from scratch which validates with good HTML/CSS.
Able to customise forms, core, themes without altering core files but by using template.php or custom modules.
Can make forms from scratch using the API - with validation and posting back to the DB/email
Can create custom modules from scratch utilising core hooks and module hooks.
Be involved with the community, understand the naming conventions, CVS system and ideally have submitted some code or revisions.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. However the following are widely used:
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Hooks
The most important hooks to learn, to create a basic module are probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
I good understanding of client-server architecture, how servers and browsers works. And knowledge of php and mysql, templates engines. And of course, you should also read Drupal documentations.
Able to create a custom Theme from scratch which validates with good HTML/CSS and also pays attention to usability and accessibility. (Whilst still looking kick-ass).
You usually don't want to create themes from scratch but from a starter theme like Zen instead.
For Drupal you will need:
PHP, it's a PHP framework, so to really understand and use it, you need to understand PHP.
SQL, the list of SQL serves that Drupal can use is growing, but you will need to understand * SQL, relational database and how to setup some basic architecture.
Javascript (and jQuery). Drupal uses the jQuery js library, so it will be a lot easier if you not only, know how yo use javascript, but also understand how to use jQuery and some of it concepts.
The hook system and how you can alter Drupal core and modules implementing hooks.
The naming convention for hooks, theme functions etc.
Modules
It's not easy to make a must know module list, as not only is the modules you use very dependent on the site, but also how you use them. The two top modules in Drupal is.
Views
Know how to make basic views and blocks.
Know how to make more complex views with relationships and terms.
Know how to use hook_views_query_alter, to make complex queries.
Know how to use hook_views_default_views, to create specific views.
CCK
Know how to setup content - what field types to use.
Know how to create your own field_formatters - the foundation for theming CCK fields.
Another module that I find very powerfull once mastered is Panels. It allows you to do a lot of complex and difficult things with very little and simple code. There is a lot of hooks you need to learn, and not much documentation. But once you understand Panels, you find that you time has been well spent.
Hooks
The most important hooks to learn, to create a basic module is probably:
hook_form_alter() - change forms without changing code.
hook_menu()
hook_theme()
hook_nodeapi() - almost anything regarding nodes
hook_schema() - create tables
hook_install() / hook_uninstall() - create tables and clean up.
hook_perm() - when you need special access control.
hook_init() - things to want always to happen.
hook_user() - if you need to tap into user actions or modify the user object.
You don't need to use all of these hooks all of the time, but they are some of the most used ones.
Great list so far! Some others for consideration:
Ability to use Drush to update or setup a site
Strong understanding of good best practices configuration for performance, security and SEO of a Drupal site (think launch checklists)
Having submitted a module to Drupal.org (however simple) or submitted a patch (the process of getting a CVS account and getting your first code in is instructive to the community and to standards)
You don't need SEO skills for templates, drupal usually helps with SEO alot. Ofcourse a developer who will slice a design must know that all headings must be done with h1,h2,h3,h4 tags. that's really basic one. everything all is up to drupal..
as for my opinion to be a drupal "developer", you need some very basic skills in PHP. Because drupal is really written without object-oriented programing, and without DESIGN PATTERNS, so these are two things is really makes you a programmer.. without them it just [sorry for this word] bullshit not a programming.
I think anybody can install drupal or wordpress or some cms-made-simple, systems if you have at least once connected to ftp in your life... to develop plugins for them is a requires basic skills of php. Ofcourse if you'll find skillfull developer then he will know oop basic, and will write plugins with OOP and that code will be really NiCE! =)
Being able to edit existing functionality (core or module) without touching the core or module and knowing whether to put it in template or a custom module.
As we anything web related these days, you really must have a good understanding of the HTTP protocol. You also need a good understanding of JavaScript, the DOM, CSS and HTML5. Knowing a bit of jQuery is not enough for a developer, you need to understand what your are doing with the DOM, HTML5 APIs and CSS in order to build features and behaviours into the browser. You also need to understand the Drupal JavaScript APIs, both on the server side (hook_library(), #attached, etc.) and the client side (Drupal.behaviors, etc.)
You also need to known the various APIs of Drupal. The Form API is not the only one. You need to understand the Menu system (page, access, title and delivery callbacks, how to pass parameters to them, etc.), the Queue API for asynchronous operations, Batch API for long running operations, Entities and Field APIs for user editable structured data, Theme API and Render Arrays for anything presentation, Cache API, Schema and Database APIs, File API, Cache API and the Localization API.
I downloaded GraffitiCMS the other day(now open source and free), and like a lot of what I see, but what I really want to use it for, is to add CMS capabilities to an existing asp.net database/application.
Without getting bogged down with all the details of my app, can someone give me the basic 'approach' that should be taken to add custom content to Graffiti; content that won't be a 'post'?
I've seen for example, how to add custom-widgets to Graffiti - basically inherit from the widget class, compile your dll and plop it into the correct directory and it becomes part of the system. Is there a way to do something similar for the main content areas?
For simplicity sake, pretend I have a non-graffiti database with gig's of data that I want to display on the website using standard asp.net grid's and forms. I realize I could just go in and hack apart the source code to integrate my existing app, but that is likely not the correct approach.
Not looking for a complete solution her, just a pointer and what areas to investigate...thanks.
If you check out the latest source of Graffiti (or the 1.3 branch that was recently created), support was added to put widgets anywhere you want on any page. There is a new chalk function - $macros.Widget - that provides you with this ability. Dan Hounshell wrote a blog post on how you can use this new functionality:
http://danhounshell.com/blog/graffiti-cms-1-3-add-a-widget-anywhere-in-a-view-with-new-widget-macro/
If you're looking for something different than that, just let me know - we're working to make Graffiti even better for situations just like you are currently in.
What we have done to be able to integrate Graffiti CMS with our current ASP.NET projects is to create a post in Graffiti called "hidden" and then with our standard .ASPX pages we call a class in our Render Override that pulls the "hidden" post (ie: site.com/hidden/) and uses the header and footer to wrap the Graffiti theme around our custom .ASPX page. We use some HTML comments in the "hidden" post to be able to parse the header and the footer. It is kind of a hack, but has worked out really well for us.
I think you're trying to put the cart before the horse - depending on the size and amount of functionality, I would be looking to rebuild it after learning the development platform of my CMS system of choice.
I'm pretty much in the same boat right now. I have avoided Graffiti because I have to learn "Chalk" (whatever that is) and Umbraco (using XSLT for layouts is retarded). So far, this leaves me with Sitefinity at the top of my list and Telerik have just pulled the free version!
I may end up grabbing a very basic CMS which is easier to customize. I know this doesn't directly answer your question, but it may give you some food for thought :-)