This is a little bit frustrating, but I will live,
I am trying to use VBO to remove content from front page and i get the error above. i am trying to understand the source of the problem but no bulk operation is working right now on my website.
In addition, going back to my content view (I am using a custom view with filters) I got these messages.
Notice: Undefined index: step in views_bulk_operations_form_validate() (line 548 of /var/www/vhosts/new.julib.com/httpdocs/sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: step in views_bulk_operations_form_submit() (line 590 of /var/www/vhosts/new.julib.com/httpdocs/sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: selection in views_bulk_operations_form_submit() (line 635 of /var/www/vhosts/new.julib.com/httpdocs/sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: operation in views_bulk_operations_form_submit() (line 635 of /var/www/vhosts/new.julib.com/httpdocs/sites/all/modules/views_bulk_operations/views_bulk_operations.module).
I Googled all over but could not find anybody that got the same problem. I suspect that there is a problem with another module but Can't understand which one.
Thanks for the help,
Yaron
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedCan you update to latest 7.x-3.x-dev (or beta3) first?
Your line numbers don't match mine and I have no idea how old your code could be.
Also, what kind of a view are you using? (an export might be useful) If you try a default vbo view (admin/content2 for example), does it work there?
Nobody has reported an error like that in the previous few months, hence your ineffective google search.
Comment #2
ymeiner CreditAttribution: ymeiner commentedSorry, I udated to last dev during the writing of the post. I am on the last dev (edited the original post with the correct error).
I am using the /content2 that i improved by adding more fields.
Thank you and sorry for the messy post
Here is the view:
Comment #3
bojanz CreditAttribution: bojanz commentedDid you manage to solve this?
I couldn't import your view because it has custom fields, it would need to be packaged in a feature together with all fields in order to work...
Can you check that you have a recent Views 7.x-3.x-dev version?
Your error messages say that the form state (data from the form) is empty, which is why VBO craps out. Maybe kind of caching problem / caching module.
I'm guessing that without access to your site (which is something I don't do) I won't be able to solve this, so I'm closing the issue.
Comment #4
ymeiner CreditAttribution: ymeiner commentedplease contact me, I am ymeiner everywhere (gmail,facebook, twitter, skype...) so i can give you privileges for one day.
Yaron.
Comment #5
bsorrells CreditAttribution: bsorrells commentedJust thought I would give a +1 on this. I experienced both of the same errors. After unpacking the latest dev code, the errors went away and the operation completed just fine.
Comment #6
awolfey CreditAttribution: awolfey commentedI'm getting this error also, with latest devs of views and vbo. In views_bulk_operations_execute(), both $selection and $operation are NULL.
Interestingly this view is working on my local dev machine, but not on the client's machine. Client machine is PHP Version => 5.3.8, mine is PHP Version 5.3.2-1ubuntu4.10. Drupal Codebase and db are the same.
Comment #7
kostask CreditAttribution: kostask commentedI am having the exact same error. In my case the error appeared after I enabled the commerce stock module.
The commerce stock module adds to the product(s) a new required field, stock.
In my case I had already created some products, so their stock value was not set.
Executing any rule via vbo on products without the stock being set, results to this error.
If I set the stock to any value, I can execute rules via vbo on it without any problems.
It is a problematic behavior as I was actually using vbo to mass set the stock values. :)
I am using views 7.x-3.0-rc3 and the latest vbo 7.x-3.x-dev
The error I get on executing delete:
Fatal error: Call to a member function aggregate() on a non-object in /sites/all/modules/views_bulk_operations/views_bulk_operations.module on line 676
and then
Notice: Undefined index: step in views_bulk_operations_form_validate() (line 535 of /sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: step in views_bulk_operations_form_submit() (line 577 of /sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: select_all_pages in views_bulk_operations_form_submit() (line 623 of /sites/all/modules/views_bulk_operations/views_bulk_operations.module).
Notice: Undefined index: operation in views_bulk_operations_form_submit() (line 625 of /sites/all/modules/views_bulk_operations/views_bulk_operations.module).
on a stock update rule I get:
Fatal error: Call to undefined function rules_ui_element_fix_empty_after_build() in /includes/form.inc on line 1828
Again both errors disappear when I set the stock to anything.
Comment #8
starsinmypockets CreditAttribution: starsinmypockets commentedI'm having the same issue. I updated to 3.x-dev and am getting the following error:
PHP Fatal error: Call to a member function aggregate() on a non-object in /srv/www/mtairy.toomodernmedia.com/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module on line 764
preceded by:
Notice: Undefined index: step in views_bulk_operations_form_validate() (line 621 of /srv/www/mtairy.toomodernmedia.com/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module). =>
Notice: Undefined index: step in views_bulk_operations_form_submit() (line 664 of /srv/www/mtairy.toomodernmedia.com/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module). =>
Notice: Undefined index: select_all_pages in views_bulk_operations_form_submit() (line 711 of /srv/www/mtairy.toomodernmedia.com/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module). =>
Notice: Undefined index: operation in views_bulk_operations_form_submit() (line 713 of /srv/www/mtairy.toomodernmedia.com/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module). =>
To be fair I've hacked the heck out of this commerce install so I'm not sure if this is really a bug, or more of a support request. Nonetheless, I would love any input you might have as to the nature of the problem here...
Comment #9
bojanz CreditAttribution: bojanz commentedI honestly have no idea how to debug this blindly.
Something is crashing your forms, the form_state doesn't contain the relevant data, and VBO doesn't know what to do.
You should enable a VBO default view (admin/content2 for example) and test with that. If you changed anything on it, revert it to the default, then test.
Also try disabling any module that might alter the form and cause it to crash.
It can either be caching (the form cache gets dropped somewhere) or a module that alters what shouldn't be altered.
Comment #10
bojanz CreditAttribution: bojanz commentedClosing this issue:
Debugged the same issue today and it turned out that the form cache was setup incorrectly: #1422070: All bulk operations broken.
So my hunch was correct. If you're having problems, go to settings.php, see if a line has "cache_form", comment it out, and retest.
If there's no such line, but you have alternative caches set up there, you probably need to add it ;)
In any case, nothing I can do from the VBO side.
Comment #11
ErnestoJaboneta CreditAttribution: ErnestoJaboneta commentedJust wanted to share my experience since I had the same problem. I needed to delete about 20,000 nodes and I'd get the aggregate error if I tried to process more than 100 nodes. I couldn't find any cache_form line in my settings.php and I wasn't using the commerce module. To work around the issue I made a new view with minimal settings. Just the title and VBO fields. I'm happily back to deleting thousands of nodes at a time now!
Comment #12
vml-bsummers CreditAttribution: vml-bsummers commentedI am having the same problem, and like #11 a new view fixes it for a while but when I start rolling that into a feature and deploying it it soon becomes broken.
unlike the other issues I do not have any alt cashing implemented and no line in my settings.php so im not sure how I can fix this.
Comment #13
Ralf Eisler CreditAttribution: Ralf Eisler commentedI am having the same problem with 7.x-3.0-rc1.
Comment #14
bojanz CreditAttribution: bojanz commentedRefer to #10.
Feel free to open a new issue if you can provide actual info for fixing the issue (which so far has always appeared because of misconfiguration of the server on the user side).
Comment #15
afmdsouza CreditAttribution: afmdsouza commentedI am having the same issue with VBO 3.x-dev and Views 7.x-3.3. Initially there was no issue when the view had few columns, the problem cropped up when new fields were added to the view. I could temporarily address the issue by reducing the number of rows per page, after sometime this workaround no longer worked.
Looks like Forms cache is causing this issue (I don't have any custom cache directives in settings.php, but using VBO 'pass row' feature). Forcing rebuild of the form by commenting '$form_state['cache'] = TRUE' at line 289 in views_bulk_operations.module fixes this stopping issue. I know it is not a proper fix, just hoping it provides some lead to the maintainer.
Comment #16
bojanz CreditAttribution: bojanz commented@alfired
$form_state['cache'] = TRUE; is a recent addition, and it means we are hitting the cache more. Unfortunately, not having that line causes a serious issue (#1460154: Incorrect form values selected for operations).
When do you get the error? On which step?
Does it also happen if you try an operation that doesn't need "pass rows"?
You could try testing with "Execute arbitrary PHP script", and then "Modify entity values", for example.
Basically, I want to see if "pass rows" is responsible. That functionality will need to be reworked soon anyway.
Comment #17
afmdsouza CreditAttribution: afmdsouza commented@bojanz
I get this error just after selecting the rows of the view and clicking on the action button (i am using 'each option as separate button'). Just tried without the 'pass row' setting, the problem persists. I shall test with "Execute arbitrary PHP script" and report back shortly.
Comment #18
afmdsouza CreditAttribution: afmdsouza commented@bojanz,
I tried both 'Execute arbitrary PHP script' and 'Modify entity values' actions on this view, both resulted in 'Call to a member function aggregate() on a non-object' error. For this view, I have set 100 as 'Number of entities to load at once' and view has pager setting of 20 items. I have 28 fields in this view.
Comment #19
bojanz CreditAttribution: bojanz commentedAre you sure you don't have a custom form cache setup somewhere?
Because the default cache goes into the database, the limit is "max_packets", and if VBO breached that, you would have / should have got an angry red DB error. The fact that you didn't tells me it might not be hitting the database.
In general, there's nothing I can do. You have a huge and unusual number of fields. I, myself am just using Form API and don't have many knobs to turn or lines of code to tweak.
You can either reduce the number of fields or tweak your db / drupal installation (not sure what should be changed though).
Any further insight would require me to have direct access to your setup, and even if you wanted to give me that, I'm busy for the next two weeks.
Comment #20
afmdsouza CreditAttribution: afmdsouza commentedNo I have not set any custom cache, there are no DB errors. The forms cache is being stored in cache_forms table. May be it is the number of fields that is tripping Form APIs, unfortunately I can't reduce them in this view. Thank you for your quick response and work on VBO.
Comment #21
bojanz CreditAttribution: bojanz commentedOkay, so you've looked into cache_form. Can you tell me how big the cache entry is for your page? (order the table by created DESC, and see the first item)
I have a regular content view, 8 columns, three of them are Field API fields. Nothing special.
So what I did is: I cloned that view 300 times (!), and stored each one in the form. The resulting cache entry size was 2.2mb (1.5mb for 200. 1mb for 100). VBO kept functioning normally (tested with 10 selected rows).
Can you also see what the max packet limit on your server is? 1mb? 16mb?
Comment #22
afmdsouza CreditAttribution: afmdsouza commentedThe length(cache_form.data) is 42913 bytes. The site is being developed on my laptop, the server configurations are at defaults. The mysql server max_allowed_packet=1mb and client max_allowed_packet = 16mb. Though I now have a large number of fields, but the error started when the fields were around 7-8.
Comment #23
bojanz CreditAttribution: bojanz commentedAnd the same problem happens on both the laptop and the server? Is the cache entry the same size on both environments?
If your cache entry is really 42kb, then that's nothing and there's no reason for form state to get dropped.
There's some other (probably server) factor here that's causing the problem.
Comment #24
afmdsouza CreditAttribution: afmdsouza commentedI don't have an access to the server yet, I should have it soon. I have tried rebuilding the site in a different web root (on same laptop) without using the database dump, the problem is same. I shall try it on a different machine and let you know.
Comment #25
bojanz CreditAttribution: bojanz commentedAnd we're back to #10.
Comment #26
afmdsouza CreditAttribution: afmdsouza commentedAt last I got hold of a production server and managed to deploy this site. There are no errors on this Ubuntu based linode server on the same codebase, hence this can be closed as it a environmental specific issue .
Comment #27
andreypaa CreditAttribution: andreypaa commentedI also had this problem, as I have been exposed to a limit of 50 nodes show. I changed to 20 and it worked.
Comment #28
nonzero CreditAttribution: nonzero commented#27 work around works for me. I get
when I try to do a multi-step bulk operation (workflow state change) on a view with 150 items despite me selecting only one item to operate on. I set the view's pager to 100 items, and the same operation works with no error.
Interestingly, when I do a single-step operation like unpublishing nodes, I get to the confirmation form without the error. Maybe the solution is to prune $form_state before sending it to the confirmation form.
Comment #29
bojanz CreditAttribution: bojanz commentedPlease read the whole thread. Without info on reproducing this (and so far it has been a server issue every time), you're not really contributing anything.
You didn't even specify your VBO version...
Comment #30
fonant CreditAttribution: fonant commentedI have this problem on one of my sites. The nodes have large KML fields, which has helped me narrow down the issue a bit.
VBO 7.x-3.0-rc1
No commerce or non-standard Drupal caches.
No database errors.
Testing with "Execute arbitrary PHP script" with an empty script. Test passes if we get the "You selected the following items:" page. Test fails if the confirmation page doesn't load, and we get the errors mentioned at the top of this issue.
* Issue occurs when fields with large data sizes are included in the view output, even if truncated to a small number of characters. Removing fields with large data sizes reduces the problem significantly.
* Issue occurs when the total data gets above a certain limit: total data being number of number of view rows * total viewed field data size.
* Issue only depends on the size of the page, so you can display just a few items and then happily update many hundreds more on pages of results that aren't shown.
MySQL max_allowed_packet=2M
Comment #31
bojanz CreditAttribution: bojanz commented2M is way too small, you will need to increase it. I will document this in the README.
Nothing I can do there, that's just Drupal setting the form cache.
Btw, the current MySQL default is 16M.
Comment #32
ymeiner CreditAttribution: ymeiner commentedThis is something that is not being addressed in a lot of modules, even core ones. there must be a way to calculate the amount of memory and the size of the packet and break the operation to batches that fit the server's limits. It's not only VBO, it is also in AJAX file upload and the indexing.
Comment #33
sletis CreditAttribution: sletis commented#27 works for me also!!
Comment #34
tame4tex CreditAttribution: tame4tex commentedI would like to further support and emphasize bojanz comments in #31. If you are getting this error to check your MySQL max_allowed_packet setting. By default this is usually set quite low eg 1M.
I am using VBO 7.x-3.0-rc1.
Got the same error mentioned in this issue. Found the issue was associated with the number of fields in my view. Less than 8 fields ok, greater than 8 fields resulted in the error.
Checked my MySQL max_allowed_packet setting it was 1M. Increased it to 10M (I am on a VPS) and the error is no longer occurring.
Comment #35
rjjansen CreditAttribution: rjjansen commentedSame problem here!
Notifications:
Undefined index: step in views_bulk_operations_form_submit() (line 650 of /home
Undefined index: select_all_pages in views_bulk_operations_form_submit() (line 681 of /home
Undefined index: operation in views_bulk_operations_form_submit() (line 683 of /home
Fatal error: Call to a member function aggregate() on a non-object in /home/sitename/public_html/sites/all/modules/views_bulk_operations/views_bulk_operations.module on line 733
Strange, that after one year there is no clue of what the issue is. I'm running a very small site and encountered a lot of spam in the forum although you have to login to access the forum and post.
Comment #36
ransomweaver CreditAttribution: ransomweaver commentedFor me this error was caused by too small max_packet_size for mysql.
Error (and only this error) in /var/log/httpd/error_log:
PHP Fatal error: Call to a member function aggregate() on a non-object in views_bulk_operations/views_bulk_operations.module on line 728
How to check:
login mysql on the command line, e.g. mysql =uMYUSR =pMYPWD
then: SHOW VARIABLES LIKE 'max_allowed_packet';
should print
+--------------------+---------+
| Variable_name | Value |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+
which is 1 mb-- too small.
so edit /etc/my.cnf to add this under [mysqld]
max_allowed_packet=16M
then restart mysql (CentOS example): service mysqld restart
problem solved.
Comment #37
squarecandy CreditAttribution: squarecandy commentedmax_allowed_packet=16MB fixed it for me too.
Changing the MYSQL settings to match your site's needs is a much better solution than #27's suggestion to severely limit the number of rows in your view to match the default available memory.
If you don't have command line access or are totally lost reading #36, ask your hosting tech support to help you set your mysql database's max_allowed_packet setting to a higher value.
Comment #38
cfox612 CreditAttribution: cfox612 commentedI'm getting this error, doesn't seem to matter if I select all or just 3 nodes to export. I've tried exporting the nodes as an XML, DSV, again, doesn't matter, this error continues to be thrown.
#10 - Checked, do not have that line in my settings.php file (or anywhere else that I can find). If someone has any other ideas of where this content might be located I'm all ears.
#27 - I lowered the number of nodes I was attempting to export and that didn't change a thing.
#36 - I'm on the acquia dev desktop and my max_allowed_packet is 128M, so clearly this isn't the issue either.
Since this issue is being solved so many ways it doesn't seem like the real issue is being solved - just bandaids here and there to control the bleeding rather than fix the source.
Comment #39
bojanz CreditAttribution: bojanz commentedLet us know if you find a fix that works for you.
I myself have never been able to find an actual problem both on my and on at least 4 installs from this issue, so I'm not interested in pursuing this further.
Comment #40
DerTobi75 CreditAttribution: DerTobi75 commentedHi,
I can reproduce this error!
When I have a view and it contains 50 items, I get this Fatal Error. When I set the shown items to 25, I can use VBO.
Regards,
Tobi
Comment #41
bojanz CreditAttribution: bojanz commentedReopen the issue with a patch only.
Comment #42
shadysamir CreditAttribution: shadysamir commentedJust got the same error with latest dev and reproduced with the same steps, having an exposed items per page pager option and changing it from the default value.
Comment #43
SGhosh CreditAttribution: SGhosh commented#10 confirmed -
From link:
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
in settings.php
EDIT:
I went back to check with another filter set and then tried a vbo operation and it gave be WSOD again, with the same errors in logs.
EDIT:
Setting max_allowed_packet to 16mb did the trick.
Thanks everyone.
Comment #44
henrikakselsen CreditAttribution: henrikakselsen at Frontkom commentedWas getting this error using memcache, and commenting out the memcache settings in settings.php got the page loading again.
Comment #44.0
henrikakselsen CreditAttribution: henrikakselsen at Frontkom commentedreplaced the quated to last view
Comment #45
geek-merlinI can confirm this fatal error. In one install i can reproduce it whenever i thigger a VBO from a view with "show all items" (1-999 of 999) applied. Triggering the same VBO with a smaller limit (1-50 of 999) gives no fatal.
The error appears in the first $operation->aggregate() check in views_bulk_operations_execute().
Later on i'll try reproducing this with latest dev.
Comment #46
Ronino CreditAttribution: Ronino commentedmax_allowed_packet = 16M instead of 1M worked for me, too.
Comment #47
dpfitzsi CreditAttribution: dpfitzsi commentedConfirmed: updating max_allowed_packet does fix this issue (in our case 32M).
Comment #48
s427 CreditAttribution: s427 commentedI have the same error. It's on a brand new computer on which I've imported an existing project. VBO was working fine on the old computer, but now I can't get it working at all, even when I select only one node to modify.
I've already checked the mysql config (my.ini, via XAMPP control panel), and the "max_allowed_packet" variable is already set to 128M. I tried pushing it to 512M, with no greater success.
Using VBO 7x-3.2
Edit: Actually, I've performed some more tests, and the problem occurs not depending on how many items are selected for operation, but on how many items were displayed in the view where you select the items. If the view has 100 items or less, VBO works fine even if all items are selected for modification. If the view has more items (I don't know where the limit is exactly), then VBO shows the error when attempting to modify the items, even if less than 100 items are selected for modification.
Comment #49
Nux CreditAttribution: Nux commentedI can confirm that (as in comment #48) upping max_allowed_packet to 100M didn't work.
To solve this I had to disable __showing__ long fields (columns). Other page in the view can happily use long columns (only the page with Bulk operations have to use the shortest columns possible). Oh, and the column values were not very long when displayed (they were trimmed to maximum of 200 characters), the column values were long in the database.
It seems strange that Bulk operation that deletes rows (nodes) is using text columns in any way (it should be using NID only). Shouldn't it? Even for updates current value is not used... Or is it?
Using VBO 7x-3.2 on Drupal 7.34.
Comment #50
joseph.olstadthis issue still occurs in latest dev. I have 12000 nodes. I attempted to try the suggestion from comment #49 but I think I'm missing a step.tried either with the latest stable version or with the latest dev, except with the latest dev I get 4 undefined index errors on the selection screen
**EDIT** adjust your mysql setting for max_allowed_packet , increase to 32M or higher. ALSO, you will need to make sure that your log file size is set correctly. Increase the log file setting in my.cnf
For us, in my.cnf , the log file size was incorrectly set to lower than default values. (don't ask me why)
we had to increase the log file setting in my.cnf, then all the problems related to the vbo errors went away.
Pretty obscure as you wouldn't intuatively expect a mysql log file setting to cause an exception in vbo!
Comment #51
larowlanFor anyone else who encounters this and MySQL configuration doesn't solve.
I was able to reproduce this on a custom build, but the source was nothing to do with VBO.
The issue was form_get_cache() wasn't finding the $form_state entries.
form_set_cache() was writing them just fine, and I could see the records in the cache.
cache_get was reading the record back fine, but this line was failing:
Because getMultiple has this hunk:
The issue in my case was a custom __wakeup method on my entity class that was throwing an Exception, which was being silently eaten by DrupalDatabaseCache::getMultiple.
Note that DrupalDatabaseCache::set also has a similar 'catch and swallow exceptions' approach.
So if you're getting this issue and can't fix it with MySQL configuration, stick a debug breakpoint in both of those catch blocks and see if something is going wrong in serialize/unserialize __sleep/__wakeup that is causing the form_state to silently fail cache_set/get
Hope that helps.
Comment #52
dromansab CreditAttribution: dromansab commentedHello,
I am reproducing this error only for non-administrator users...
I've removed and reinstalled the module and I've set max_allowed_packet to 64M but nothing happens.. Does somebody have the same issue?
Thanks
Error:
Log:
Comment #53
joseph.olstadHi dromansab, I have seen similar issues that you describe occur when the mysql log file reaches its limit , please review your mysql configuration , increase the log file size limit, see my comment #50
Comment #54
dromansab CreditAttribution: dromansab commentedYessss! I've increased innodb_log_file_size variable It works!
Thank you very much for your help!
Comment #55
tterranigma CreditAttribution: tterranigma commentedI am having this problem from time to time with admin_views related operations, and disabling and re-enabling that module solves it every time.
Comment #56
bellagio CreditAttribution: bellagio commented#54 works for me. thank you.
Comment #57
darksnow CreditAttribution: darksnow commentedFor me this issue was due to the size of the Body field in the content itself.
I've imported a lot of content from another system using fields and for some reason a few of the posts have Base64 encoded images in the body field. If any of these massive posts are in the list that is selected for manipulating by VBO it causes this error.
My solution was to single out that post, change it's format to RAW (no filters applied to the HML in Body) and manually publish. After that the VBO 'publish' operation would work unless there was another problem post in the list. I worked this out performing the VBO operation one page a time.
Comment #58
joelpittetNot sure we can act on this, mostly is large packets from skimming the results. Closing this for now to clean up the queue. Feel free to re-open if you have a way to resolve this in VBO but doesn't seem likely considering the age, lack of patches and the comments regarding MySQL packet sizes.
Comment #59
scottybrookie CreditAttribution: scottybrookie commentedChanging max_allowed_packet to from 1M to 16M, as in #46, fixed the problem for me as well.
Comment #60
Pene CreditAttribution: Pene commented#27 worked as a "backup" solution.
Comment #61
efpapado CreditAttribution: efpapado at Ramsalt Lab commentedI have the same issue with
max_allowed_packet
set to 256MB.I'm using a view that is limited to 20 rows and only has the vbo field and nid. I'm triggering a custom action.
I have asked our hosting service to change to 512MB, to see what happens.
Comment #62
joelpittetWithout solid steps to reproduce this issue will remain closed.
Comment #63
Marco Aurelio Rocca CreditAttribution: Marco Aurelio Rocca commentedSame here: table with a lot of columns, kinda long texts in 2 of those many columns. Workaround #27 worked (reduce # of registers shown in table). Maybe too many information in the page.
Comment #64
Bruno Vincent CreditAttribution: Bruno Vincent commentedTried this on April 2019 with latest D7
You need to set the view to less than 100 items , then it works. I set it to 90 and it works fine
Comment #65
joseph.olstadsee solutions 54, 46, 56:
#1326584-54: Fatal error: Call to a member function aggregate() on a non-object in .../views_bulk_operations.module on line 686
#1326584-46: Fatal error: Call to a member function aggregate() on a non-object in .../views_bulk_operations.module on line 686
#1326584-56: Fatal error: Call to a member function aggregate() on a non-object in .../views_bulk_operations.module on line 686
Comment #66
Bruno Vincent CreditAttribution: Bruno Vincent commentedFile to change is into the Xampp via control panel, the my.ini file, not settings.php ;)