I grabbed a copy of the latest dev (the one committed march 7 2015) and noticed that my forms are not working correctly in my sub-theme. Just wanting to make sure I wasn't losing my mind I downgraded to the commit made on march 6th and made sure that things were working then grabbed the tar.gz again and was able to recreate the issue. Of particular note is the log in form and the deletion of a comment.

I then disabled my custom theme and set the default theme to just the regular bootstrap theme and tried to log in and saw the same issue.

Anyone else running into the same thing?

Thanks in advance.

CommentFileSizeAuthor
#9 cached_element_info-2448259-9.patch6.42 KBmarkhalliwell

Comments

markhalliwell’s picture

markhalliwell
Primary language English
commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)
Related issues: +#2447947: Allow dynamic #process and #pre_render hooks for elements

It's likely due to the related issue. Did you clear your cache?

noticed that my forms are not working correctly in my sub-theme

Could you be more specific? This isn't a lot to go on.

noopal’s picture

noopal commented

Hi

I had the same problem, a few form elements were duplicated like vertical tab items.

But the main problem was forms wasn't saved.

For example I couldn't uninstall modules. Then I logged out and couldn't log back in, when I entered my details to the user log in form I could click submit but the page would just refresh.

I did what the poster said and downdated to the release before to log back in.

Christopher Riley’s picture

Christopher Riley commented

I did indeed clear my cache both from the web interface as well as drush cc all from the command prompt. Since there is at least one other person with a similar issue I will see what I can do about doing some additional debugging if I have some spare time later this afternoon. Since I am using too many mods that alter the form for login I will dig around on the delete comment form.

glynster’s picture

glynster commented

I too encountered a form issue related to Ubercart "Add to Cart" buttons. With the latest dev version (March 7th, 2015) installed, cache cleared etc all my "Add to Cart" links were going to random urls all over the site. For example if I cleared the caches all "Add to Cart" links were going to another random url. Once I downgraded to the previous version (March 6th, 2015) cart links were working as expected.

I hope this gives a little more info to help pinpoint the issue.

Christopher Riley’s picture

Christopher Riley commented

I did a little bit of playing around and tracked things down as far as a caching issue. Looks as if I disable caching in bootstrap_element_info_alter by commenting out $element_info = $cache->data; When I comment this out I am not getting the double #process and #pre_render of

#process (Array, 2 elements)
0 (String, 22 characters ) bootstrap_form_process | (Callback) bootstrap_form_process();
1 (String, 22 characters ) bootstrap_form_process | (Callback) bootstrap_form_process();

#pre_render (Array, 2 elements)
0 (String, 20 characters ) bootstrap_pre_render | (Callback) bootstrap_pre_render();
1 (String, 20 characters ) bootstrap_pre_render | (Callback) bootstrap_pre_render();

It appears that when the caching is active it is not setting type since with what I am reading we should be getting something like:

#process (Array, 2 elements)
0 (String, 22 characters ) bootstrap_form_process | (Callback) bootstrap_form_process();
1 (String, 22 characters ) bootstrap_form_process | (Callback) bootstrap_form_process_TYPE();

#pre_render (Array, 2 elements)
0 (String, 20 characters ) bootstrap_pre_render | (Callback) bootstrap_pre_render();
1 (String, 20 characters ) bootstrap_pre_render | (Callback) bootstrap_pre_render_TYPE();

Suggestions?

markhalliwell’s picture

markhalliwell
Primary language English
commented

Which element is this happening on?? I cannot reproduce this.

Christopher Riley’s picture

Christopher Riley commented

It shows up when I try to delete a comment. Here is how I was doing it.

1) Load Firefox log in as Admin.
2) Post Comment to a node.
3) hit the delete comment link and examine the form and you will see the TYPE issue within a DPM of the form.
4) Delete comment
4) Load Chrome and try to log in and it will try to bounce you to the last form rendered which in this case is the comment delete form.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Title: Latest Dev form issue? » Cached element info replaces dynamic element info
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

Ok, so this is in fact a huge bug. Leave it to people to supply dynamic data inside a "base" info array. I would even go as far as saying that it's actually a "core bug", however given that it's likely there are other modules out there that do the same thing, I've taken a different approach to caching discovered element information. I'll upload a patch shortly that y'all should apply to confirm that this indeed fixes everything.

FYI, the "bug" in question is in system_element_info() for the "form", type's #action property, which changes each page request:
'#action' => request_uri()

markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Active » Needs review
StatusFileSize
new cached_element_info-2448259-9.patch6.42 KB
glynster’s picture

glynster commented

Resolves the UC "Add to Cart" issues right away for me. Thanks for being so fast solving this!

  • markcarver committed 7d041a6 on 7.x-3.x 
    Issue #2448259 by markcarver, cmriley: Cached element info replaces...

  • markcarver committed fffbbe8 on 8.x-3.x 
    Issue #2448259 by markcarver, cmriley: Cached element info replaces...
markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Needs review » Fixed

Well, it was my fault (#2447947: Allow dynamic #process and #pre_render hooks for elements)... lol

Anyway, thank you for confirming :) Glad people are actually testing the dev branch!

Now, I just need to get people actually testing an upgrade from 7.x-3.0 so I can release a stable soon.

markhalliwell’s picture

markhalliwell
Primary language English
commented

Also FYI, this is the change record regarding what all this fuss was about: https://www.drupal.org/node/2448505

glynster’s picture

glynster commented

I tried to update to the latest dev version and received this error:

File bootstrap-7.x-3.x-dev.tar.gz_date=1425742081 is corrupt (wrong [error] md5 checksum)

glynster’s picture

glynster commented

I have a couple of sites I could test upgrading from 7.x-3.0 to the latest dev version, is that what you mean?

Christopher Riley’s picture

Christopher Riley commented

Everything is working perfectly! Thank you so much for looking into this and getting it dealt with.

Christopher Riley’s picture

Christopher Riley commented
Status: Fixed » Closed (fixed)
markhalliwell’s picture

markhalliwell
Primary language English
commented
Status: Closed (fixed) » Fixed

#15:
This is due to a delay in packaging/CDN file deployments when using Drush, it should resolve itself over time.

#16:
Yes. I would recommend doing it locally instead of actually upgrading a live site though. That way you can constantly test dev against a real site as many times as you'd like (can't undo what's been done on prod, only locally). I would, but do not have any viable candidates.

#17:
You're welcome :)

#18:
"Closed (fixed)" is assigned automatically by the system after two weeks of inactivity. "Fixed" is the appropriate status so it remains visible to others and gives them a chance to comment.

Christopher Riley’s picture

Christopher Riley commented

So noted thanks

glynster’s picture

glynster commented

Thanks for the feedback all working perfectly!

  • markcarver committed 7d041a6 on 7.x-4.x 
    Issue #2448259 by markcarver, cmriley: Cached element info replaces...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.