I'd like to create a static captcha for plone.app.discussion with cultural context: people from a certain nation would be likely to understand the question and know the answer.
plone.app.discussion documentation page discussed about captcha architecture
http://packages.python.org/plone.app.discussion/captcha.html
However, it does not provide steps what you need to do to get your own captcha running or what adapters etc. are involved and how to register it. It mentions
<meta:provides feature="plone.app.discussion-captcha" />
... but does not give any hint what this should do.
You can always extend the comment form with a custom captcha field and validator. See http://packages.python.org/plone.app.discussion/howtos/howto_extend_the_comment_form.html for details about how to extend the comment form and http://svn.plone.org/svn/plone/plone.app.discussion/trunk/plone/app/discussion/browser/validator.py for how to write a custom validator.
Monkey patching code is not necessary. The only reason for captcha specific code in p.a.discussion is, that most captcha solutions (such as plone.formwidget.captcha and plone.formwidget.recaptcha) are only generic plone.z3cform fields/widgets. These generic fields/widgets need to be plugged into the comment form to make the captcha field and validator actually work (which right now happens in p.a.discussion itself, but this could also happen in the captcha field packages).
Related
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 have a Plone Site where anonymous users create a "Subscription" object for a conference.
Fact is: a malicious user can call this screen a lot of times and crash my site. I can use a captcha to avoid it, but I would like to use it only after "x" attempts of the same user, something like the SO approach when a user tries to post a lot. Is there a module that does this for me? Show a recaptcha after a user tries the same url too many times?
For a start content in not the solution to everything. In your case having a custom content type for handling subscriptions seems like an overkill. Always ask yourself if what you are doing is really content-ish. Does it need to be contained, navigable, searchable whatever else content can be? For a conference subscription definitely not.
In brief you could:
Create a form and save its data in lighter objects than full content or use sql.
Use Products.PloneFormGen, which also has captcha support.
Concerning the captcha if you go the manual way and create everything yourself, you could use cookies to "remember" visits. See How do you get and set cookies in Zope and Plone?
It's obvious that your system is subject for manipulations in form of mass-registrations in every way without further measures like a captcha or additional email validation after submission of the registration form. But this is independent of flow control, DDOS etc.
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.
(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.
Stackoverflow members,
How do you currently find the balance between javascript and code behind. I have recently come across some extremely bad (in my eyes) legacy code that lends itself to chaos (someHugeJavafile.js) which contains a lot of the logic used in many of the pages.
Let's say for example that you have a Form that you need to complete.
1. Personal Details
2. Address Information
3. Little bit more about yourself
You don't want to overload the person with all the fields at once, so you decide to split it up into steps.
Do you create separate pages for Personal Details, Address Information and a Little bit more about yourself.
Do you create controls for each and hide and show them on a postback or using some update panel?
Do you use jQuery and do some checking to ensure that the person has completed the required fields for the step and show the new "section" by using .show()?
How do you usually find the balance?
First of all, let's step back on this for a moment:
Is there a CMS behind the site that should be considered when creating this form? Many sites will use some system for managing content and this shouldn't be forgotten or ignored at first glance to my mind.
Is there a reason for having 3 separate parts to the form? I may set up a Wizard control to go through each step but this is presuming that the same outline would work and that the trade-offs in using this are OK. If not, controls would be the next logical size as I don't think a complete page is worth adopting here.
While Javscript validation is a good idea, there may be some browsers with JavaScript disabled that should be considered here. Should this be supported? Warned about the form needing Javascript to be supported?
Balance is in the eye of the beholder, and every project is different.
Consider outlining general themes for your project. For example: "We're going to do all form validation client-side." or "We're going to have a 0 refresh policy, meaning all forms will submit via AJAX." etc.
Having themes helps answers questions like the one you posted and keeps future developers looking in the right places for the right code.
When in doubt, try to see your code through the eyes of someone who has never seen it before (or as is often the case, yourself 2 to 3 years down the road), and ask yourself: "Based on the rest of the code, where would i look for this function?"
Personally, I like option number 3, but that's just because it fits best with the project I'm currently working on and I have no need to postback or create additional pages.