Fatal error: Call to undefined function _bootstrap_process_element()

If #1 doesn't make any change, you can just add somewhere in your custom module:

require_once(drupal_get_path('theme', 'bootstrap') . '/theme/process.inc');

Thanks, comment #3 helped me. I added this to the top of ds.module

This seems to be a problem with display suite. I was getting this error using the theme seven.

I apologize in advance for my improperly titled patch, this is the first patch I've ever submitted.

@bdanin, thanks for your first patch! However, I must point out at least one major flaw with this:
79,308 reported installs of DS - 19,330 reported installs of Bootstrap === 59,987 sites that just broke because they're "required" to load a file that doesn't exist.

That's why @honeym00n said to use it in a custom module. I'm not entirely sure neither module should be patched though. This issue has been marked appropriately already since the reporter found that the reason this is happens is because the max_input_vars PHP variable needs to be increased.

Please don't let these technicalities stop you from submitting further patches though :D We always appreciate the help!

Fair enough, changing max_input_vars in PHP didn't solve the issue for me. Also I only got the error on theme seven, so I didn't think it was a bootstrap issue. But on second glance, the require is pulling in a file from the bootstrap theme.

To clarify a bit more, this happened to be when using Display Suite in theme seven to create a dynamic block that pulls in existing content as a node-id. However, the final output of the site is using the project/bootstrap theme.

I'm pretty sure this is a Bootstrap issue that needs to be fixed. What appears to be happening is that Bootstrap is registering a "#process" function for form elements in a hook_element_info_alter() call:

<?php
function bootstrap_element_info_alter(&$elements) {
  foreach ($elements as &$element) {
    // Process all elements.
    $element['#process'][] = '_bootstrap_process_element';
?>

This _bootstrap_process_element function is in the /theme/process.inc file. If you're on an admin page and you don't have the Bootstrap theme set as your admin theme, this function isn't defined because that file isn't included. That's what's giving the error.

I was able to fix this by adding the following hook_init() function to a custom module, but I don't think that's a reasonable solution for most users:

<?php
/**
 * Implements hook_init().
 */
function mymodule_init() {
  global $theme_key;
  if (strpos($theme_key, 'bootstrap')===FALSE) {
    include_once(drupal_get_path('theme', 'bootstrap') . '/theme/process.inc');
  }
}
?>

I'm not sure what the real solution would be because Bootstrap is trying to change something when it's not really loaded. Maybe there needs to be a "Bootstrap Tools" module that is a dependency and includes this function?

What admin theme are you using?

I'm using Rubik, but I can recreate the issue in Seven as well.

I still cannot reproduce this using latest core, bootstrap, ds and seven.

drupal_alter() only invokes the active theme (theme used for that path) and it's inherited base themes. So if your admin theme isn't bootstrap based, bootstrap_element_info_alter() shouldn't be invoked at all, which is what adds the #process function.

I'm really at a loss here. I've gone through display suites code (and know it quite well), but haven't found any code that actually loads the default (not active) theme's template.php file.

Do you have any other modules enabled that might have their code entangled with enabling/including a theme's template.php file?

I think I see what's going on.

In my case, the problem is occurring on an admin form for the OpenX module. And it only happens when I submit the form after previously clicking an "Add zone" button which makes an Ajax call. This Ajax call is made to the path "/system/ajax". As that call is processed, it doesn't think it's on an Admin page, so it uses the default theme for the site (Bootstrap). Bootstrap adds that "process" function to the elements; but, when the form gets submitted, it's no longer using that theme (it's using the Admin theme) and that function is no longer defined.

I've confirmed this by having bootstrap_element_info_alter() make a call to watchdog(). The $theme_key global variable is set to bootstrap during the "/system/ajax" call.

I couldn't recreate the issue myself with an "Add another item" button on a node edit form, even though that does make a call "/system/ajax". Bootstrap's bootstrap_element_info_alter() function does not get called. I added a watchdog() call to a hook_init() function; and, for that call to "/system/ajax", $theme_key is (correctly) set to "seven".

I'm not sure what that OpenX form is doing differently. Whatever it is, Display Suite may be doing the same thing.

I can reproduce this using message and locale modules. Up on message type creation I switch the language for the message and hit save, which results always in a fatal error with PHP Fatal error: Call to undefined function _bootstrap_process_element() in /project/includes/form.inc on line 1815

Same problem. I have node with multiple images field which used ajax. After deleting one of the images and trying to save node I get the error:

Fatal error: Call to undefined function _bootstrap_process_element() in /[..]/includes/form.inc on line 1850

Increasing max_input_vars did not help.

@jrb (8): Yes, Bootstrap certainly needs a 'Bootstrap Tools' companion module because currently it's trying to do things in the theme layer that need to be done earlier -- and the possible overridden in the theme layer. Adding a hook_init() to fix this is, as you say, not a great solution and carries a significant cost with it.

This is a flaw in the current architecture of the theme, and unfortunately requires developers to jump through hoops to resolve -- or make unwise direct connections between other modules and specific themes.

@seycom (14): We fixed this with theme-level form alter to re-attach the right files required. Unfortunately Drupal assumes this can only happen to Module files, so I had to cut/paste/alter some core code into the template.alter.inc file.

E.g. Our fix...

/**
 * Implements hook_form_FORMID_alter().
 * - Fix _bootstrap_process_element() AJAX error
 */
function YOURTHEME_form_YOURFORMID_alter(&$form, &$form_state, $form_id) {
  // Add required bootstrap/theme/process.inc file for AJAX
  $module = 'bootstrap';
  $name = 'theme/process';
  $theme = 'YOURTHEME';
  $type = 'inc';
  if (!isset($form_state['build_info']['files']["$module:$name.$type"])) {
    $file = drupal_get_path('theme', $module) . "/$name.$type";
    require_once DRUPAL_ROOT . '/' . $file;
    $form_state['build_info']['files']["$module:$name.$type"] = $file;
  }
}

@Jim Kirkpatrick (15): Thank you, no errors now!

The solution in #15 isn't very manageable, in the long haul. Now that we have the _bootstrap_get_base_themes() helper function, I think we can safely wrap the include of the alter file. Here's a patch. Please see if this fixes this issue and I'll commit it.

@Mark Carver (17): for me it does not work. After patch I get error on all pages:

Fatal error: Call to undefined function _bootstrap_get_base_themes() in /[...]/sites/all/themes/bootstrap/template.php on line 56

You have to apply it to the latest dev... That function does not exist in 3.0.

Can anyone actually verify that the patch in #17 works against the latest dev for the issue at hand (I am unable to reproduce). I would like to make sure this is the correct course of action before committing.

No, the patch in #17 did not work for me. I used the latest dev version from 2014-Jun-13, applied the patch and I am still getting:

PHP Fatal error: Call to undefined function _bootstrap_process_element() in /drupal/includes/form.inc on line 1808

By the way, I am not using Display Suite. Only the Seven theme for admin pages and node/add forms, and a bootstrap sub-theme as the site's default theme.

Patch #17 - I've got no errors on latest dev.

Update: I've got no error #14 on latest dev with no patch as well.

I updated to latest dev version and the subjected error disappeared for me. I did not applied any patch.

Ok. It seems that the latest dev does not contain this weird error https://twitter.com/jrbeaton/status/480072261740027904

I suspect that perhaps maybe a core or DS update may have fixed this. Regardless, if it creeps up again, try applying the patch in #17. Only re-open again if that patch fixes it.

Just in case someone else hits this thread, the max_input_vars=1000 was the problem for me. Lots of fields on the content type caused it, and bumping the value to 2000 fixed it.

I was having the same issue:

Fatal error: Call to undefined function _bootstrap_process_element() in /[..]/includes/form.inc on line 1850

when arranging fields in display suite teaser view. For me it seemed to be an issue with the read more control module. After disabling, the error disappeared.

Problem is correctly explained in #12 : when you're using an ajax thing (like anything having an option in "manage display" screen, or things like that) in admin theme, theme "switches" to front theme, and the problem occurs.

New version of patch (#17) compatible with bootstrap 7.x-3.0.

Edit: instable patch.

Patch in #28 worked for me. The Fatal error seems random to me - I was editing fields fine and then tried to configure another field and bang! Applying the patch allowed me to continue with configuring the field.

This most certainly is an issue with the number of people reporting it (add me to the list), reopening although I know it is difficult to reproduce.

I'm getting this error with 7.3.0, when I change any field display (from Visible to hidden) in the "Manage display" for any content type. Really weird!

I get this error when I try updating the display for the leaflet format for a geofield. none of the patches so far work. When I switch to a different theme, I have no issues.

I was having a similar issue to this. (using a Bootstrap Subtheme). In #8 I noticed the topic of admin themes potentially being an issue. I (re)enabled the overlay module, and all is working. This is really only a band-aid to the larger issue, but hopefully this might help others

I was having this issue trying to use hierarchical select with bootstrap. I can confirm the patch fixes the problem. Here's a reroll against -dev.

Oops -- that last patch included a separate fix too.

I should just give up i think.

Alter is in includes now

I still would like to figure out the steps to reproduce this. I have never seen this error in any site build I have done with this base-theme.

What modules does this conflict/needs testing with?

What conditions must be met for this to happen?

A theme's alterations are not supposed to be called unless the theme is active, see drupal_alter().

The patches above are simply a hack. I would really prefer to not put this in if possible and, instead, get to the root of the issue.

Agreed it seems kinda hacky and shouldn't be necessary. Possible we're exposing a core bug? I'll try to look into a reduced test case. If it's helpful, where's what's involved for me:

• I use bootstrap as the base theme for an admin theme, but in this case not for the public theme
• The error occurs when processing an ajax callback on an admin page, specifically from hierarchical_select.
• Here's the hook_menu definition for the callback:
  

    $items['hierarchical_select_ajax'] = array(
      'page callback'     => 'hierarchical_select_ajax',
      'delivery callback' => 'ajax_deliver',
      'access arguments'  => array('access content'),
      'theme callback'    => 'ajax_base_page_theme',
      'type'              => MENU_CALLBACK,
    );
  

Note that the callback above is NOT an admin theme. You'd think it wouldn't engage the alters at all.

I've had to hack the hierarchical select module to get it to run properly due to a couple issues, so it will take some effort to make a test case using that specifically.

Ah. Actually I would surmise that it is actually a hierarchical_select bug and not a core issue. I've seen this module be a culprit on more than one occasion in this queue.

Just briefly looking through their hooks and JS, I'm not entirely sure they're using the theme callback, ajax_base_page_theme() appropriately in conjunction with their own $.ajax() requests. It is probably not sending the ajax_page_state[theme] in the POST request, which that callback needs. See: /misc/ajax.js.

These are added to Drupal.ajax requests based on the #ajax element provided in render arrays. Many custom modules that implement their own custom JS or hooks, bypassing core, do not realize the complexity behind the built-in AJAX requests and forget to add in the things that you would normally get.

I'm also attaching a related issue, which may or may not help remedy this particular use case.

I have applied patch provided at #36 but the issue remains the same.
It may have passed the tests, but it doesn't work in my case.

@j_nunes, the patch is a stopgap measure hack. This is why it hasn't been committed nor is it going to fix all use cases. Issues like these often are due to some module not using an API correctly (probably with AJAX requests) as I mentioned above with the hierarchical_select module. I would recommend trying to pinpoint what module it is and open an issue there and referencing this one.

For me the issue occurs under the following circumstances.

1. Admin theme is Seven, Default theme is a subtheme of Bootstrap
2. Node add form has dynamic dependent fields followed by a file upload field
3. After triggering the dynamic dependent field, the ajax response contains the Drupal settings json object, including the theme key, which is my subtheme, rather than the admin theme, seven.
4. The next ajax response is from the file upload, which then loads new css (from my custom theme) and everything looks wonky.
5. After submitting I get the fatal error. I guess my theme is half loaded but the base theme isn't.

So for me the solution must be to prevent the theme from switching on ajax responses, but I don't know if that's a Bootstrap problem, or a DDF problem, or some other module's problem.

Edit: I should add, that if I upload the file first the theme key returned in the ajax response is "seven". I can then update my DDF field (which returns my subtheme) and successfully save the node.

I don't know if that's a Bootstrap problem, or a DDF problem, or some other module's problem.

It's not Bootstrap, but you definitely hit the head on the nail: "DDF/some other module's problem".

I should add, that if I upload the file first the theme key returned in the ajax response is "seven".

I am assuming this is core's file upload? If so, this makes sense as core follow's it's own APIs :)

I can then update my DDF field (which returns my subtheme)

Seems like you figured out who is responsible.

File upload can be either core or media module, both present the error. I think you're too quick to blame ddf, other users have reported similar issues with hierarchical select, and display suite. So it sounds more like a general Ajax issue. Maybe it's bootstrap, maybe it's a core bug, maybe it's something like ctools.

Just read #42, I'll look in to that further.

I'm definitely convinced now that this isn't something that should or can be fixed in this project. Please open issues for the module that is incorrectly dealing with AJAX requests. Please do not re-open this issue.

Patch fatal_error_call_to-2156371-17.patch was failing on 3.x-dev.
I recreated a patch which works for me.

A version of the patch for 3.0

Edited: DO NOT USE THIS PATCH
_bootstrap_get_base_themes() is missing in 3.0

If patch bootstrap-undefined_function_bootstrap_process_element-2156371-28.patch for version 3.0 fails to succeed try this patch for 3.0.

And finally the really really correct patch for 3.0
Have to use array_key_exists instead of in_array as the theme machine name is in the keys, not in the values of the array.
So patches bootstrap-undefined_function_bootstrap_process_element-2156371-28.patch or fatal_error_call_to-2156371-52.patch only work as long your NOT on a theme which has a bootstrap as base theme but fail when you are.
Use this one for version 3.0 instead.

@jummonk, this issue will not be committed to the repo. Please see the issue summary.

Like @incrn8, just increasing PHP config variable max_input_vars from 1000 to 1200 solved the problem for me.

I think the problem simply occurs when you have a long list of fields in manage display view using Display Suite layout. And maybe without using Display Suite it may occur too (Just read about max_input_vars config variable on php.net)

For what it's worth, I am NOT using Display suite and still get this error on node creation forms

Fatal error: Call to undefined function _radix_process_element() in /Users/danshumaker/Projects/First/git_repo/docroot/includes/form.inc on line 1850
Call Stack
#	Time	Memory	Function	Location
1	0.0007	265584	{main}( )	../index.php:0
2	0.0585	4761808	menu_execute_active_handler( )	../index.php:21
3	0.0587	4764256	call_user_func_array:{/Users/danshumaker/Projects/First/git_repo/docroot/includes/menu.inc:519} ( )	../menu.inc:519
4	0.0587	4764592	node_page_edit( )	../menu.inc:519
5	0.0589	4765272	drupal_get_form( )	../node.pages.inc:14
6	0.0589	4766272	drupal_build_form( )	../form.inc:130
7	0.0631	5363160	drupal_process_form( )	../form.inc:385
8	0.0631	5368856	form_builder( )	../form.inc:885

I tried switching to bartik for the admin theme and that did not help, nor did increasing max_input_vars to 2000.

What did work is switching to a radix theme as the admin theme.

@dshumaker, the error you provided above is for the Radix theme, not Bootstrap. As stated in the issue summary, the problem likely lies in some sort of module (not necessarily DS) that implements an AJAX request and doesn't properly send which [current] theme should be used in the request.

Thanks Mark, I knew that, but Radix is based off of bootstrap and so thought my fix might help someone.

It's based off the Bootstrap framework, yes, but not this project. It's an entirely separate base-theme: http://cgit.drupalcode.org/radix/tree/radix.info

That's interesting, I actually was using Rubik as my admin theme as @jrb was. Sorry for the mis-information. Google brought me here when I was searching for solutions.

I ran into the same issue today when creating a feature for a content type. Adding max_input_vars = 2000 to my php.ini fixed the issue for me.

Thanks,

Working with Adminimal as admin theme and had the same issue.
=> increasing PHP config variable max_input_vars from 1000 to 1200 also solved the problem for me

This issue was also present in the Kalatheme issue que: https://github.com/drupalprojects/kalatheme/issues/160

In #61 the issue was fixed but I ran into the same error when updating a node and filling out more fields. This time the max_input_vars increase didn't work but @Jim Kirkpatrick solution in #15 fixed the issue for me.

#15 isn't really a "solution"... it's more of a makeshift hack. Please read the issue summary to get a better understanding of why this is likely happening in the first place.

edit: I'm also half tempted to close commenting on this issue to prevent further unnecessary noise.

Trouble is if you can't close, as the error will still come up for people.
Fatal error: Call to undefined function _bootstrap_process_element() in /var/www/public_html/drupal/includes/form.inc on line 1850

Someone will likely make a new issue post, as this is the only place related to this error. That is until it can be passed on to somewhere else.

Changing the max_input_vars did not work for me.

Although adding this line did to the top of the ds.module
require_once(drupal_get_path('theme', 'bootstrap') . '/theme/process.inc');

This is not really a solution to hack the module and its likely to be different module for some other users, I suppose we could make a template hook to add the line in but this again is a work around and not solving the problem.

I can make a corresponding issue with the maintainer and see if they have any suggestion's but I think this is a red herring.

Ok... so, yeah... I totally spaced that this is actually really a core issue (I had made the connection, but forgot to make a comment here when I was involved with those issues).

Module/themes are really just the unfortunate casualties when core builds its "element_info" without any regards to theme context.

D8 has been fixed (see related issue) and is now sitting as a backport for D7.

For a simpler/completed D7 patch (or at least to gain some background around what is actually happening), see #2351731-9: hook_element_info_alter() does not always get invoked in themes.

I've also updated the issue summary accordingly.

Hello Markcarver,

With my site i get also this error when I save a node :
PHP Fatal error: Call to undefined function bootstrap_form_process() in /srv/data/web/vhosts/mydomain.com/htdocs/includes/form.inc on line 1850

I have tested your patch (https://www.drupal.org/comment/9701387#comment-9701387), but I get always this error. This patch don't resolve this bug for me....

For me, the only solution is to use the Bootstrap theme for admin pages, and desactivate the seven admin theme.

Are you sure? Did you clear caches after patching? It may need the D8 backport version after all (which includes cached DB entries of the element info per theme).

The only reason I am involved with this issue is because whatever does cause this issue to manifest, it does so because this base-theme takes advantage of element info altering (which not a lot of themes do, but is how the theme system is supposed to work and allows it).

Obviously there is some disconnect in an AJAX request for what "theme" is supposed to be rendering (which is ironic because not all AJAX requests need the theme initialized, but that's a side-rant).

In any case, you'll either have to live with the admin theme (for now) or you'll have to try and figure out (debug) why your installation is throwing this error. I do not have the time to handle every unique case, especially ones I don't have access to (and no, do not send me login/server credentials).

FWIW (and to repeat) I have never actually seen this "error" and agree with @BigEd (#66) that this issue is likely just a red herring.

Hello markcarver,

I have found a solution with this code (in a custom module):

function mycustommodule_init() {
	global $theme_key;
	if (strpos($theme_key, 'bootstrap')===FALSE) {
		include_once(drupal_get_path('theme', 'bootstrap') . '/includes/process.inc');
	}
}

Now, i can save the nodes from the seven theme. This is a similar solution to the post #66.
In my another websites, I get no this bug....strange...

as posted here: https://www.drupal.org/node/2529140 (which was closed as a duplicate) i'm seeing similar issues when setting a bootstrap theme as admin without a bootstrap theme on the front end.

Unfortunatly none of the patches or fixes in this issue thread seem to work, as its not just process.inc that gets called (common.inc is called as well). Manually adding in those calls to register the function causes the styling on the front end to get messed up.

So, as of yet for me atleast, no fix for this one :(

I also seem to have the same problem as #71. Unfortunately, changing themes don't have any effect, the error is still the same.

EDIT: It turns out that my problem is likely unrelated to that. Sorry.

I'm re-opening, but as a minor and postponed for the following reasons:

1. The solution in #2448843-34: [regression] Themes unable to implement hook_element_info_alter() should resolve this issue
2. No one has actually given very clear steps to reproduce this issue.
3. Thus, I have NEVER seen this fatal error and cannot reproduce it to actually "fix" it. I'm figuratively flying blind here.

Got this issue.

To reproduce.

1. Install bootstrap theme
2. Set an admin theme and other theme as not bartik
3. Load bootstrap theme on admin with

/**
* Implements the change of theme.
*/
function hook_custom_theme() {
if (arg(0) == 'admin') {
return 'bootstrap';
}
}

4. Go edit a node, see bootstrap load and fail when pressing save on a node.

#3 fixed in custom module.

@jOksanen, I still cannot reproduce with these steps. What modules/fields are being used on the node? Can you provide a screencast (movie) or screenshots (images) of this error?

I'm very tempted to close this issue again.

Same problem form me, If I try to upload a photo and save I get this error :
Fatal error: Call to undefined function _bootstrap_process_element() in /home/borgo/public_html/includes/form.inc on line 1870

Changing max_input_vars in PHP didn't solve the issue..... the strange thing is that I've been able to upload about 70 photos before the problem has manifested itself

Honestly... how am I supposed to fix this? Saying "I have the same problem" and listing the same error as everyone else isn't very useful to me. I am well aware people are having this issue.

I would love to fix this. I really don't like it when people have problems like this, I like developing quality code.

So please give me the exact steps on how to reproduce this issue:

1. User actions (e.g. navigate to X page, click X button, etc.)
2. Modules in use while this errors occurs.
3. Field type/configuration for when this error occurs.
4. Any potentially relevant or special server setup/configuration

I cannot fix something that is extremely inconsistent and non-reproducible on my end.

markcarver, I think if my memory serves me okay it seems like this issue was solved for me by #55 above. Perhaps altering that environmental variable on your install might make this issue occur on your system too.

Just to prevent too much searching down the wrong route, #55 did not fix this for me. Its still an issue.

For me to recreate simply set a bootstrap theme or subtheme as the admin theme with a non bootstrap theme on the front end. Nothing else needed

My comment #78 was in response to #77 where it was noted that changing max_input_vars did not work. This means the issue really lies elsewhere.

@N1ghteyes, you'll need to be a little more specific... I did what you suggest and did not run into any problems: http://take.ms/9GrVU

@markcarver Not sure i can be, thats literally all i did. Are you testing this locally? maybe some weird config issue for either me or you? I'd be supprised if it was though...

If i get half a chance i'll dig through my setups and see if i can find anything specifically different.

Hope it can help someone: setting the ajax path to the admin theme with admin_theme solved the problem for me with Bootstrap 3.1, after having tried without success almost all the listed patches (except the core patch suggested by markcarver, the maintenance of the project could be an issue in my case with a core patch).

I'm not 100% sure that this is the key, but the exact thing I did is set media/ajax/* to the admin theme paths in the admin_theme configuration. Removing the line from the configuration, the error comes back.
Unfortunately, I haven't managed to reproduce the error on a clean installation on the same machine.

I try to give some details that may help: I can see the error appears while editing in the node form a field with an image (with media widget in my case), and I can see correlation of the error with the presence of fields with hierarchical select and field collection. Display suite is set on the form but disabling it didn't work out. The site is quite big (100+ contributed modules) and the content types have 25+ fields.

I have this and other issue - connected with field collection theming on node edit.

Using admin theme - Seven.

1) fixed of fatal error by adding process.inc in template.php

/**
 * Implements hook_form_FORMID_alter().
 * - Fix _bootstrap_process_element() AJAX error
 */
function seven_form_page_node_form_alter(&$form, &$form_state, $form_id) {
  // Add required bootstrap/includes/process.inc file for AJAX
  $module = 'bootstrap';
  $name = 'includes/process';
  $theme = 'seven';
  $type = 'inc';
  if (!isset($form_state['build_info']['files']["$module:$name.$type"])) {
    $file = drupal_get_path('theme', $module) . "/$name.$type";
    require_once DRUPAL_ROOT . '/' . $file;
    $form_state['build_info']['files']["$module:$name.$type"] = $file;
  }
}

======

2) Second issue connected with
https://www.drupal.org/node/2156371#comment-8671153

I have field collection module installed.
And if i have > 3 items of field collection (FC) - it start error.
After you save node with 3 FC items - open edit and start delete one of the module - the theme of items inside FC - will trigger on another (seems to me Bootstrap). If you click again add/remove item - it will trigger on Bootstrap sub-theme.
Everytime it adding css of the theme.

But it happens only if items 3 and more.
If only two items - everything ok.

I didn't increase max- max_input_vars = 2000

===

I see that a lot of problems it is from Bootstrap template.php

/**
* Include common functions used through out theme.
*/
include_once dirname(__FILE__) . '/includes/common.inc';

And including other inc files.

Is there some method DO NOT include functions of theme OUT of Base/Sub Bootstrap Theme ???

If i will disable all bootstrap themes - everything working good.

We don't need Bootstrap functionality in other NON Sub-theme of Bootstrap.

Or I'm wrong?

Waiting for ideas. Thanks.

Read the issue summary (and entire issue).

---

I'm closing this since no one can seem to provide consistent steps for me to reproduce.

markcarver
I don't know my issue got to be here or somewhere.
About fatal error - already have fixed.

Please, 2 questions:

1) It is important to influence on other NON Bootstrap theme, by adding common.inc file by default (for example)?
2) About theme of items in Field collection, when we are on node edit page Add/delete items by ajax. (Entity line items)
Like in https://www.drupal.org/node/2156371#comment-8671153

About Field Collection(Entity items) Add/remove and theme using for thous fields.

Drupal 7.41

Installed
Bootstrap 3.1
Bootstrap Sub-theme
Seven theme - for Admin Theme
Field collection

Node type - Basic page
Have
Image field
Field collection field - with 3 items (important for my case) (with 2 items working greate).

I have node with 3 Field collection items.
When i remove one of them - fields in Field collection wrapper gut another theme.
After that i remove one more - and got already inluded Bootstrap Sub-theme css-s.
I mean - on the page connecting css-s of other bootstrap themes.

Please could you propose something.
I am stuck.
I could give Video )

(Also saw issues connected with entity items here
https://www.drupal.org/node/2137237
)

Or we are waiting for Patch
https://www.drupal.org/node/2448843#comment-10093134
be applied in core?

Thank you very much for advices.

Some fixing for ajax add/delete items of field collection in node/edit

Installed module
https://www.drupal.org/project/themekey

Added rule
If drupal:path = system/ajax
then use Admin theme.

It was temporary fixing of my 2nd problem from 87 post.

===
I understand that determining of base theme (is it Bootstrap or Sub-bootstrap theme) sometimes get error and Bootstrap function influencing on other themes.
Waiting of patch porting to Drupal 7.

I have same error too when I use DS module with extra fields enabled. Bootstrap sub-theme - base theme. Seven - admin theme. After set Bartik as base theme - no error.

@sashken2
That because - you disabled Bootstrap theme. It use some functionality that make this error/

Another solution of all my problems - set max_input_vars = 2000
It solved problems with theme switching in ajax (add/delete field collection items) and with with Fatal error problem.

I thinks with Bootstrap theme ON - it taking some more max_input_vars including with field collection or DS modules, when editing some nodes.

Thank for attention.

I got this error when selecting a Display Suite layout for node/fields/view. Ignoring the stack trace and resubmitting the form got me back to the chosen layout.

When first using bootstrap we had lot's of bootstrap functions triggering without having the sub theme being default. Guts feeling this is a core issue.

Sorry for the state change

@NIKS_Artreaktor I tried up to

max_input_vars = 4000

but are unable to submit my /admin/structure/types/manage/my-type/display/view page. My content type has 113 fields :(

I stopped having this issue after upgrading to 7.x-3.4.

jrb´s #8 Solution worked perfectly for admin theme Seven when trying to save after Media Browser in Lightbox. Had previously tried to increase max_input_vars=2000 to no avail.

#8 is not a "solution".............

I am un-publishing all "solutions" to this issue and closing comments. The issue summary explains exactly where the issue really lies (either a core or contrib issue).