Move the label text to the form field value

This issue makes more sense being a feature request, so I change the category.

I missed one thing: the input field value should be cleared on submit when nothing is typed in.
This is solved in this new patch.

Code optimizing is still possible. It's merely a proof of concept, but it is working.

Damn, I forgot to set the right status: patch needs review.

Thanks for your input! Not sure I want to _replace_ the current behavior with your suggestion though - I like the idea of labels actually being labels... However, I'd consider including this if it is optional and controllable from the admin page - which is not a hard task to accomplish.

I have a week of holiday and sailing upcoming, will look at this again once I'm back.

Hi tomsun,

Thx for your feedback. Allow me to adjust the patch to make it optional and controllable from the admin page.
The reason I would choose this behavior is because the css didn't work out well, right from the deployment of the module. I guess other people might have the same issue and don't want to hussle with the css.

So, wait for me when I posted a new patch.

BTW I forgot to thank you for this nice module!

I modified the patch based on your advice and it very nicely integrated now.
Perhaps you may want to check the description added in admin form, whether thats clear enough (I'm not native english, so it is hard to come up with a decent short description).

That was quick Thomas! :--)

I have problems applying it though... If you scroll through the patch file, notice it removes everything and adds it back again, only now every other line is blank. Do you think you can generate a cleaner patch? If not, I'll go through it manually when I get back somewhere around Aug 19:th.

Btw, what is the reason for adding !important to the css file? This potentially gives themers a hard time.

I'll create a new patch. I think I used a different encoding in my editor.
I'll remove the !important as well. It was an artifact from some other code. Sure, it's better to remove it.

Thx for the feedback.

This time I created a new patch with Eclipse, and it resulted in yet again the same odd diff: - the original file, + the adjusted file. Strangely enough, this only occurs with the compact_forms.module and not with the js and css file. I'm not that a cvs wizard to create the patches manually, so this is the best I can do.
The previous patches were made with TortoiseCVS. The extra whitespace between each line came from TortoiseCVS check out. Again, it only occurred with the module file and not the other 2.

I have checked out lot's of modules before, and this is the first time I encounter these problems. Just to make it clear, it's only with the module file. Perhaps you can look into it because I might not be the only one having this problem.

Anyway, the new patch is attached, based on your previous comments. Speak you after the 19th!

Is it just me or are these patches broken? (it definitely could just be me since I'm a patching rookie). I've tried to run all the patches above in OS X terminal using the patch command, and I get a different error for each one, with none of them resulting in a patched file.

Am I missing something? (changing to 'code needs review' since I haven't been able to patch successfully)

I gave it a final try to end up with a decent patch. For compact_forms.css & compact_forms.js the patch seems ok, but for compact_forms.module I still can't get a decent patch. So, there is something strange with the module file, not with the others. Perhaps some character encoding? I can say this is the only module I have problems with when creating a patch.

Anyway, I have added a zip file with the full module (remove the .gz extension because drupal does not accept .zip files). So, you can test the module in case the patch does not apply. This is actually the module I use in production.

I like the patched version a lot, as it offers both the original CCS-based and the Input value method. Testing them both is easy, and you can then choose you prefered way.

BUT, i stumbled upon a bug/quirk with the input value method :

On comment form, the default value is NOT replaced, and I end up with Anonymous (or any name I set for anonymous users, I suppose) in the field.

Which is not informative, of course :-) So maybe another option to override default input value would be nice. (in the meantime, I suppose I'll try to find a way via some theming method)

PS : by the way, will this patched version make it as 1.1 ??

There is a new version of the patched module. It solves a very minor issue: sometimes the field value was not 'grayed' out.
Nevermind if this isn't really clear. Just use this latest version and let me know when it is ok. I can make a patch from it so it can be committed. It's already to long in the queue ;-)

Thanks for the quick reaction !

Appart from the conflict with default values (in my case, I simply set nothing as the Anonymous users name, quick and dirty fix), everything seems fine. Note that I test it only on the comment form and user form for the moment.

I'll update with the new one as soon as possible.

Hi, it's me again.

I just had a feedback from an user that he could not post comments : It seems that the patched Compact Forms erase the content of the form before submitting on firefox.

What is weird is that I think I tested it and it worked, but now it clearly doesnt work anymore. It must be a javascript issue. Some conflict with another module, maybe.

Anyway I switched back to the CSS overlay way -- Too bad because I like the label-becomes-value way more.

Any hints on how to make it works ?

My advice: use the firebug plugin for firefox to find out what goes wrong. Via the console, you could change the function of the form submit action in order to do some bug testing.

any update? Thanks

subscribing

has this been successfully resolved?
thanks

@toemaz: Can you re-roll this patch against latest code in DRUPAL-5 or HEAD (for 6.x)? Your patch touched (and changed) pretty much everything, I just need the actual changes to review (and potentially commit). Thanks.

subscribing.

I guess I'll install the zip and give it a test shot...

Well, that sucked. I didn't realize the zip is for D5. My fault, but Beware!

Does this issue still exist after all? Due to recent changes, speed-ups, and other improvements I can't remember to have seen this faulty value overlay. If you test, please test with latest code in CVS, resp. the new dev snapshot of today.

@sun Sorry for my very late reply. I have not gotten the time yet to update the patch. Concerning the 'faulty value overlay', I created this patch mostly because I wanted it exactly as mentioned by a-list-apart: as a form field value rather than an overlay.

I'm still having this problem with latest 6.x code. Is it possible to apply this patch to 6.x branch?

this issue persists and is causing an error in #542588: URL error on homepage field

I have been testing this module and I am getting the following error.

when the comment is submitted, Drupal displays the following message:

The URL of your homepage is not valid. Remember that it must be fully qualified, i.e. of the form http://example.com/directory.

It seems that when the homepage field is left empty, compact forms auto completes it using the label.
When i poked around in firebug, i got the following code:

I took a couple of screenshots to help anyone who is taking a look at this.

tested this module with another drupal6 install and it worked fine. So the problem might be with my install or theme.