jefs.42

Ah, that would do it ;) I haven't actually tried the pre-2.3 version. Seems like it would work fine because if $linkList is empty it "returns". Otherwise it falls through and outputs the $info_box_contents. This was the first I've played with the silo at all so happened to be a 2.3 version. Figured maybe I was just doing it wrong that it wasn't outputting anything other than the heading no matter what page I went to, so opened up the bm_headertags_seo_silo.php to try and find out why. With the class/functions setup you have in the 2.3+ version you have this in the execute() function: ' <div class="ui-widget-content infoBoxContents">' . $this->get_list() . ' </div>' . Which would output whatever the function get_list() returns. But as mentioned above, the current code for the get_list() function never returns anything. It either a. just returns if $linkList is empty or b. still just returns because that's the end of the function So regardless of whether $linkList gets populated, or is empty, the output of $this->get_list() is always nothing. Otherwise the actual list getting seems fine. With the change I mentioned above (ie, actually returning the list when it's not empty) works nicely. It then does output a list of links - subcategories, products, etc. Thank you for this and all your addons. I've used them well So just wanted to help out in case this hadn't come up before and/or you weren't aware. The second part, like I said, was just a thought/feature request in the case where $linkList is actually empty. So then it wouldn't just output a heading with no content.

Hello, I was trying to look through the posts to see if it's already been mentioned. Didn't find anything, but may have missed it. I was trying out the silo box for the first time, but it was always empty. This is for the "greater than 2.3" files. I found that in includes/modules/boxes/bm_headertags_seo_silo.php the links are never returned. In the get_silo() function it ends with if (empty($linkList)) return; but doesn't do anything when it's NOT empty. So nothing is returned either way. I believe the code should be if (empty($linkList)) return; return $linkList So if empty, it returns nothing. But if it's not empty it returns the actual list of links that was just created. Also, maybe more of a request, but I think the output should be adjusted so that if $linkList IS empty, the box won't output anything. Currently it will output the header with an empty box. Maybe something like if (!empty($this->get_silo()){ $data = ... $oscTemplate->addBlock($data, $this->group); }

I think you might be looking for this one http://addons.oscommerce.com/info/601

I can't reproduce your issue. I can check/uncheck indivdual boxes with no problem in Firefox and IE (both 7 and 6). The default orders.php has an onclick='...' in the <tr>'s so that clicking anywhere in that row will reload the page with that item selected (barring the case that you click on the preview button which loads a new page). This contribution modifies that and removes the onclick from the <tr> and puts it into each of the <td>'s EXCEPT for the one with the checkbox. I would recheck the code around 430-450 (depending which version you're using) and compare to the INSTALL file and/or the included orders.php with your version. This is the begining of the 3rd of the 3 sections modified. It sounds very much like the onclick is still in the <tr> so it applies to the <td> holding the checkbox as well as the rest of the row. p.s. - javascript should be fine as that's what does the select all/none anyways ;)

Wanted to annouce for all those who were asking for it, and anyone who wants it that version 1.2 is now available which includes the ability to use it for deleting multiple orders at once. Note that the ability to delete is optionally, and in fact must be turned on to be used (setting is in the language file). Like the indivdual deletion, a Restock checkbox is also provided (only shows up when the Delete option is selected). http://addons.oscommerce.com/info/3749

No. And there's no plans for it, as that would start taking it back toward individualizing. If someone wanted to start a new contribution implemeting individual order options, obviouslly the code is freely available to do that. But this one will continue only being for doing the exact same thing for many orders at once.

Use a contribution such as http://addons.oscommerce.com/info/3072. I think there's at least a few other similar contribs so you might want to search for 'shipping estimate' or such.

Hi folks. I'm currently working on getting a new version up, as I noticed that the v1.0 that's was put up doesn't actually work as is (w/ no language file BUS_SUBMIT is not defined and therefor the update loop never gets run), there's some excess code (like doctype and <head> stuff stuck down in the middle of the page), all the text is moved back into the orders.php file and I believe it should be separated out. Also with making it language independent again, I'm making it so the Comment Bar buttons are defined in the language also. So you'll be able to create as many as you want, or none and just have the Reset to clear the comments field. After that, I will work on adding the Delete ability as that seems to be a favorite request. mafiouso: The select box will list any Status values that are setup in Localization->Orders Status. So, unless your 'Cancelled' does anything other than set that as the Status, just add 'Canceled' as a status option in the Localization section. And in that vain - you can add as many Status's that you want, edit the 3 that are osC defaults, etc.

Yeah, it looks like there's a few issues here that may make it rough. First I'm almost positive you can't have forms within each other. So only one takes precedence (not sure if it's which comes first or last). So by moving my tep_draw_form down to solve that, the checkboxes are no longer part of the form. So you'd have to set it up to use only one form for both contributions. But my contribution <form> submits to orders.php, and the print one submits to it's own (print_batch_process.php). So my code at the top of orders.php that does the actual updating would need moved to print_batch_process.php or vice versa. Second is that, most likely, the javascript include for the print batch just loops through all checkboxes in the form under the (understandably) notion that all of them are for the print batch contribution. Where as my javascript only loops through the ones named update_oID[]. Not all that good with javscript, so I'm not sure if or how to modify the other one to only check the print batch boxes. The last wouldn't be a huge deal if the first can be worked out. Depending on what you need to print/update you'd either have to Check All for the print batch then Uncheck All for the Update which would leave you with only the print batch boxes checked. Or you'd have to manually uncheck any you didn't want both checked.

I'm currently using my usual osC 'work' location for temporary on a current job I'm setting up, so can't try anything out with this combining right now. The Batch Update Status form (which covers the list of orders and the buttons below, submits back to orders.php. The name of the checkboxes is update_oID[] which comes back to php as an array of all checked boxes. Assuming that Batch Print also submits back to orders.php, either direction would work, but the 2 checkboxes would be easiest. Otherwise the name and variable would have to match across both. Either all the Batch Print checkbox related html/code would have to be switched to use update_oID, or the Batch Update would have to match the Print's names. One plus is that as long as no New Status is selected, it doesn't matter which, if any, boxes are check - it still won't do any of the updating code.

I'm not particularly familiar with the Batch Print contrib, though I had looked at that first when the request came in from the client. However, it did seem either not userfriendly, or just too much for what they were looking for (plus they would be the ones using it not me ;) ). It was for the Fur Peace Ranch guitar camp and they also have a lot of concerts going on, so tickets are a huge part of their sales. Since these aren't shipped and need no invoices/slips printed, they just needed a quick way to set them all to a 'Will Call' status.

I'm not sure this sounds like a 'permanent' addition, since it's heading back to a 1-by-1 sort of scenario. Though if it's not a rush or anything, I could post the code to do it here? Maybe we should start a Batch Update Status Addons contrib ;) Anyways, the way this would need done is to add a text field next to each checkbox and have it named relative to the orderID. So order ID 342's text field would be named comments342. Then while it's looping after submit you'd just set $comments and/or $notify_comments to the correct comments# for the current oID.

Still planning on it. I was hoping it would be a 'just upload these files on a clean osC'. But it's all file by file editing so it's taken longer to check into. From looking at it though, I'm pretty sure it uses 1099 as the status id. How would you see the date range working? If it's part of the same contrib would it archive those _in addition_ to any checked in the list above, or instead?