Posted by Liam Morland on November 2, 2012 at 2:33pm
2 followers
| Project: | FillPDF |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
I have a PDF file in which one of the field keys is "Date - mm/dd/yyyy". When I try to access the Edit field mapping page, which is at "admin/structure/fillpdf/147/edit/Date - mm/dd/yyyy", I get a "page not found" error. The URLs need to use an encoded version of the field key to avoid having incompatible characters.
Comments
#1
Thanks for reporting. If you've got time to post a patch I can commit it.
#2
The attached patch fixes the problem by using an encoded version of the pdf_key in the URL. It makes the URLs a bit messy since they have to be run through rawurlencode() twice. It would be tidier and work to, for example, replace "/" with "!", but then you couldn't have an exclamation mark in a pdf_key.
#3
#4
Edit link for a field called Personal/FirstName doesn't work. Only single encoding seems to be needed. Troubleshooting patch.
#5
Let me know if this one still works for you. I'd commit it, but I assume you did not double-
rawurlencodewithout a good reason. Let me know more about your use case, browser, anything that might be affecting things.#6
Sometimes, %2f gets decoded and sometimes it doesn't. It depends on the setting of Apache's AllowEncodedSlashes Directive. Encoding it twice will always work.
#7
I think you didn't double-decode then, so it failed on my system. I got a page not found. Will take another look.
#8
Double decode works. Patch attached. Does this look good to you? If so, will commit.
#9
Ah, with my Apache setting, I didn't need to double decode because Apache was already doing that. I will test your latest patch Monday and get back to you.
#10
#8 works for me.
#11
Pushed (06cd92a).
#12
Oh yeah. D6.
#13