Closed (fixed)
Project:
Forward
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
18 Mar 2010 at 18:51 UTC
Updated:
10 Aug 2011 at 00:36 UTC
Jump to comment: Most recent file
Comments
Comment #1
berliner commentedI propose the attached patch that resolves the issue for me.
Comment #2
Architeck commentedRan this patch against the stable release 6.x-1.16 and it fixed the issue,
Marking as tested.
Comment #3
chrisla commentedThis patch didn't work for me.
I only installed Forward for the first time yesterday, using release 6.x-1.16. Initially, the link would show up in the block. I changed it to the form view to see how that looked and now when I select the link view, it won't change back.
I've uninstalled the module and reinstalled it and it still loads the form view regardless of any settings.
Comment #4
chrisla commentedComment #5
crimsondryad commentedI tried the above patch and it didn't work. After more investigation, I discovered that the database is storing a 1 for var forward_block_form. Line 1174 checks for a string ("link"). I've attached the patch, have a look and see if this works for anyone else.
Comment #6
crimsondryad commentedComment #7
quotientix commentedThanks berliner, worked for me!
Comment #8
crimsondryad commentedDid you use berliner's patch or mine? His didn't work for me, which is why I changed it. Basically, what his does it convert the value inserted into the database....which isn't really necessary. What needed to happen is to change the code to match what actually lived in the db.
Can you try mine out? I need it reviewed so we can get it into the module.
Comment #9
seanrThis is working fine for me in the dev branch now. I think I must have already fixed it at some point. There will be a new release out soon.
Comment #11
ken hawkins commentedI had the 6.x 1.19 release installed and was getting the bug that produced the full form in the block regardless of the radio option selected.
After reading this I updated to the latest DEV release and it persisted despite the usual cache flushing.
But applying Berliner's patch at #1 fixed the issue for me.
Comment #12
ken hawkins commentedAlso, should have mentioned that crimsondryad's didn't help the issue for me.
Comment #13
alex.pilon commentedThe problem is that the form is storing the wrong value in the database. On line 1162 you could just add array keys to the #options entry as such '#options' => array('form'=>'form', 'link'=>'link'),
If you do this then the rest of the code works as it should because it is working with the correct values. This also opens the opportunity for i18n because now we can wrap the labels with the t function.
Word
Comment #14
crimsondryad commentedthat sounds like the issue I was having and attempting to fix with my patch. But hey, array values = less ambiguity. Wrapping with the t() is just a bonus. :P
Comment #15
seanrChecked #13 into the dev branch, can you give it a try?
Comment #16
TJM commentedI have tried the patch and the two other options, but I only see the full Form rather than the Link. Is there one combination that is successful?
Comment #17
alex.pilon commentedYou should only need to use one of the options.. start with a fresh copy of the module and try my solution.
Comment #18
alex.pilon commented@seanr: seems to work the way its supposed to... thanks!
Comment #19
manoloka commented#13 worked for me
Comment #20
john.oltman commented