Hoza

Just to follow up on my "pre-MS1" installation of this contribution... I wanted to let everyone know that I did get it working without any problems at all. Again, my OSC is 2.2CVS dated around December, 2002. Thanks for the great work! :)

Ack!... Stop the presses! Ever have a moment when you wish you could retract a statement, realizing only a few moments too late that you didn't think hard enough about the thing you were saying??? Well, I just had one of those. :/ I actually uploaded a duplicate of the full fedex1.php module into the languages directory instead of the correct one for that place. Doh! The same names confused me I guess... sheesh. Not enough coffee or not enough sleep.. take your pick. Sorry about the irritation. The module looks like it's working. I have it loaded up in Admin and I see the options there. I will proceed to test it once I get my reply from FedEx that I sent in earlier so I can do testing. Thanks again and sorry for the clutter. I appreciate all the work you've done on the mod and thanks for the help. Regards, Paul Hoza NearlyEverything.com

I have grep and ran that command, but I chickened out after it sat there for over a minute... I aborted it (Ctl-C) after that, so let me know if I just need to let it run longer. It worried me that it took that long. (I'm paranoid when it comes to doing things on the server that I'm unfamiliar with.. grep is something I haven't played with much. :) Otherwise, the only modules in the shipping dir are the defaults (flat, item, table, usps, zones) and an upgraded ups.php that is from the "UPS Choice 1.6" contribution. I have to remove the fedex1.php module from the directory in order to access anything in the admin>modules>shipping screen, otherwise I get the error I already mentioned. Please advise on the grep issue, if that will help with a solution... sorry I'm too paranoid to just let it run for a couple minutes, but it doesn't seem like it should take that long.

I'm hoping to get this sweet-looking contrib working on my "pre-MS1" install of OSC. My install is current to about Dec. 2002, so I have what I understand to be the "new checkout" stuff. I see in the PHP info that I have --with-curl listed. So, my problem occurs when I load up the Admin>Modules>Shipping page. I don't see any list of shipping modules and such, but instead see the following message: Fatal error: Cannot redeclare class fedex1 in /path/to/catalog/includes/modules/shipping/fedex1.php on line 24 I've gone roughly through this thread and have not yet implemented any changes to my fedex1.php script other than to edit the personal info as per the install instructions. Does this contrib work with pre-MS1 carts or not? I had hope that it would, based on the contrib description, since I don't really have time right now to upgrade to MS1. Any help would be appreciated. Thanks, Paul Hoza NearlyEverything.com

Am I missing something with the issue of multiple sub-categories? I'm thinking that you could put a product into any category you want, as long as they all existed if it's a 3+ deep tree. When you look in the database, all the categories are listed linearly anyway, it's just the variables for parents and children that creates the trees. If you mean having the upload create a tree from scratch for a new product, what about just putting in several sample products into a small "tree-building" upload? It would have one product entry for each category that would need to be cleaned up later, but at least you'd get the functionality of EP now! :) product1; cat_root_name = "Main Cat 1"; categories_name = "sub cat 1"; product2; cat_root_name = "sub cat 1"; categories_name = "sub cat 2"; continue... Now, when you add your products, you just fill in the proper categories to add them in. Again, I may be missing something in this discussion about what you're after. I haven't played with anything more than a one-deep tree for now, so I might be way off on the topic. --Hoza

This is a great idea! I've been mulling it myself, it seemed odd that there was no way to delete the product. We'd need to decide on the rules for this deletion to occur: If you delete a product in a subcategory/category, does it continue to exist in other categories? If no other categories use it should we "turn it off"? Let's talk this one thru, it makes sense to have some functionality like this. Let the talking commence... ;) Here are some of the first concepts that occurred to me: (please understand that I'm not really sure what it takes to implement this kind of stuff, so I'm sorry if it's outrageous at any point! I'm working from a design perspective here. :) ) 1) I like the idea of just using the v_prod_avail field as a simple deletion indicator, since it would be easy to see in your working .csv file. Removing the date and changing to '-1' or such would be an obvious option here, as DicE said. Alternately, we could make it more verbose like the EOREOR you've already implemented and require "REMOVE" or "DELETE" in that field to make it more accessible. Only question here is if you can have EP accept a char string in a date field or if a number would be easier to process. 2) Possibly add another field like "product_state" or something so we can derive functionality beyond only a product deletion? Using this, we may have some of the following options (just examples): 'ADD' = add or update as an active product using the v_prod_avail field as the available date (current functionality)'OUT' or 'OOS' = set product to "out of stock" in the database, but keeping the entry and the existing product dates 'OFF' = set product to Inactive in the database (opposite might be 'ADD' state, rather than adding an 'ON'?) 'DELETE' = delete product from the database I know that's a bit much, but it would be cool to take a whole set of products offline at once without remming them from the database. :) 3b) Now that I'm thinking about this stuff, I want a feature in osC (and subsequently in EP) to specify a date to deactivate a product's availability!! Oooooh. Sure would be nice to set a limited availability period for a product, where you set a date range to have the product active... "mmmmm... forbidden donuuuuut..." Oops... sorry, but I got a bit off track there. :D 4) Regarding categories, I see this as being intuitive: When you have a product set to be deleted (by whatever method) and the category fields have valid, existing category data, EP checks for these various conditions and deletes the product accordingly: -If 'v_category_root_name' and 'v_categories_name' exist, remove product from that category only.-If 'v_category_root_name' exists (other is empty), remove product from all child categories of this root category. -If both category fields are empty, remove product from all categories. -I think there might be another option here that would set the product to be deleted from the database entirely, but that may be tied to the deletion flag, rather than category fields? I'm thinking of various other things, but for now this basically expresses my initial thoughts on the subject. Thanks for your hard work, Tim (and now others who are adding code to the fire! ;) )

The v_date_avail field is not working quite as I would like... I'm not sure if you have a particular reason for it or not, (if so, plz tell) but here's what I see: When you upload a new product with a blank v_date_avail field, the products_date_added field gets filled with the current date/time... cool enough. However, when there's an existing product and you export the .csv from Easy Populate (1.2), it pulls the products_date_added field from the database and sticks it into the v_date_avail field of the .csv. Now, if you upload it again, the v_date_avail is same as the prod_date_add value, so the database would be updated to that value (I'm guessing here.. I haven't tried it, since I don't want to affect all the dates I have in there now.) If you don't see a problem yet, let's use an example of a product: added on the 14th and set to become available on the 18th. Exported on the 15th to change the description and uploaded again. Now the product is set to become available on the 14th. Workaround is to remember to change the v_date_avail field to 18th again before upload... oops, I forgot... also forgot with the other 82 products. Well, that's according to my calculations anyway... maybe I overlooked something, as I'm getting REALLY tired. Having said that, I'm now wondering if this was just a simple oversight and I had no reason to explain all that. Hrmmm. Bed time, obviously.

I have two things so I'll break into 2 posts I guess... 1) I haven't gotten past using version 1.2, since it did everything I needed, and by the time I logged back into here, you were rumbling up to 1.5 already! Wow. Thanks a TON for you hard work! That leads me to a suggestion that always seems to ruffle feathers of debate... version numbering. I just thought I'd suggest you implement some variation on your numbering scheme to help distinguish between feature-added versions versus bug-fixing versions. I'd personally like to see something like "major.minor.bugfix" or "major.minorX" where X=letter. Anyway, this might make a quick bug fix at v1.2.4 or v1.2d more distinguishable from v1.4 "Now with large-file support!"... additionally, this gives you much more leeway as you rapidly approach version 2.0!! :D

I don't have Excel anymore, but I wanted to prod someone with it to look something. I remember having this problem with Excel placing quotes around a text field automatically. You wouldn't see it until you opened the exported file (friggin' stupid if you ask me... mostly since I don't know why that "feature" would be desireable.) Anyway, there is a setting that will change that to not place the quotes in there. Ugh... I don't know what the setting is and I don't have Excel installed anymore to check, sorry. It might be something to do with the formatting of cells or something. I'm really sorry to not have better info, but I'm working from long-ago memory here. I do remember setting something that may have been file-specific, rather than a permanent Excel setting. It simply stripped the quotes from around the various text fields of the export. Look into settings regarding Text-type fields, I think, at least as a start. Hope this helps... I certainly think it's nice of Tim to work quote-checking into Easy Populate, but I think it's kinder of us to just do away with the problem in the first place from the Excel side. Of course, I also hope I'm remembering things right and I'm not just wasting space here! :D

Firstly... HOLY COW!! This is definitely cool to see this project flying along like this! I agree Tim, it is exciting and fun... well, to watch from this side! :) I'm really appreciating all your hard work, as well as Dynamok for getting the ball rolling! Okay, I thought I'd fire off a potential suggestion here, but it's not complete. I only have what I believe to be the beginnings of a solution for you using OpenOffice.org. The reason I'm not totally complete with this is that it seems possible in theory, but my personal knowledge stops short of giving you a complete solution... ANYWAY: If you try OpenOffice.org's Calc program (same as Sun's StarOffice Calc, I think), there is a feture in there to save selections of a spreadsheet as Database Ranges. These ranges can then be easily re-selected by a quick double-click. What I'm thinking here, but I don't really have the time to research fully on my own, is that you may just be able to set up a range for each 300-item block. Then, it seems like you might be able to just open your file and select an existing range and export it to it's own file. Again, I'm not sure if this is possible, but I looked a bit into things and maybe there is a macro (OOo has a macro language in it) that would automatically dump the selection into a new file. It may even be possible to make a macro that would automatically run through your datafile and save out all the db ranges in one shot. Additionally, a macro might be able to make the selections/ranges for you in the first place, too. I know, I know... this is more like a "wouldn't it be cool!" kinda thing, since I'm not doing it first. At any rate, it seems well within the realm of possibility if any of you know how to crank out OOo macroes and such. There are also a lot of sources for that type of stuff on the Web. Now, having said all that, it may take longer to solve the problem this way than it will take Tim to implement his "large file" optimizations!! Hehe... oh well, I'm getting into the spirit here I guess. Wish I could contribute more. :)