OSCMax 1.7 / Stock Easy Populate - No will products import.

[tdiaz]

I can manually add products, I can save a file from the Easy Populate module, it will have the data I added in it, but when I even just make a change using pico in the shell and put the file right back, no changes are made.

Not to mention that if I put a 50 product listing in, no changes happen either. But no errors are posted to the screen.

I do have ccc/temp (ccc instead of catalog)
It's permissions are 777

I changed the default cache from /home2/whatever/tmp to /tmp

I see this is a semi comon occurance in the forums... with no real solve.

I have this exact same problem on two different installs;

Mac OS X 10.3.8 and Mac OS X Server 10.3.5

Any hints?

Thanks,
Tony

[michael_s]

I am not clear what the problem is. Are you using the easypopulate interface to then import your changes? You make no mention of that (I just want to be sure).

Check the easypopulate settings in your easypopulate.php file to make sure it is correctly setup for your server.

[tdiaz]

This is all I ever see after selecting a file to insert into the DB;

It is the same file downloaded - with just one change, I changed a price, in one line item and added the second one listed. It never shows and the other price change never reflects.

I deal with delimited files on a near daily basis, and have been for years. So this part is nothing new to me. Unless there are Gremlins needed for OSC to work..

(Sample screen shot)

EasyPopulate 2.72-MS2-Max en : English(1)


File uploaded. 
Termporary filename: /var/tmp/php43men5
User filename: EP2005Mar14-1402a.txt
Size: 103

_______________ ...
|Upload EP File

My file:

v_products_model v_products_price  v_products_quantity   EOREOR
PRODMOD  29  20  EOREOR
PRODMOD2  30  21  EOREOR

Envision Synthetic tabs in there.

I do not have /catalog/temp/, but I do have /ccc/temp/, that is I changed the name of catalog to ccc. The $tempdir/2 variables just reference the directory name itself and not the path to it, so I assume that as long as I have /temp in the root of the OSC directory and it's called 'temp' that no changes are needed there.

[tdiaz]

Anyone?

Perhaps it's permissions somewhere along the line? Besides /catalog/temp ..

I realize I mangled the topic title, it should have said "OSCMax 1.7 / Stock Easy Populate - Products will not Import.

I must have gotten distracted.

[tdiaz]

Perusing several OSC sites, it seems as if this is a very comon problem yet it seems that no one ever solves it. No one ever posts a solution, I've been all through admin/includes/configure.php and admin/easypopulate.php, doesn't matter. It just does not work and gives no indicator as to why. No products ever appear in the database. Period.

I can even take the file that is saved in the temp directory from EP, change one character, upload it, NO CHANGES ever post. NO ERRORS ever indicated.

It's either everyone gives up or the answer is some super secret deal that you have to be elite to understand.

[buglerroller]

Im with you.... Just not going to use EP right now.

[ranz]

i know most people would be "frustrated" by repeating answers --> but I think the above posts have a decent point. I'm using a brand-new stock MS2-MAX install with no modifications. No products exist in the db.

I also can't get EP to work either. THERE ARE NO ERROR MESSAGES.

1. catalog/temp is CHMOD 777
2. I SPLIT THE FILE - the split doesn't work - no file in the /temp dir
3. I MANUALLY SPLIT THE FILE - not even 1 row works!!
4. I DOWNLOADED the EP....txt file and uploaded that WITHOUT ANY MODIFICATIONS - it goes straight back into the EP page - no "thank you, file imported successfully" message or anything
5. the actual php code of EP could do with some error processing.
6. IF it's a time-out issue - surely you can test for this using php (you can) and have it fail before it does anything and say "your time-out is set to xxx --> you need a minimum of yyy to be able to upload more than 100 rows"

What if we want a shop with > 20,000 products? is everyone saying that Osc is no good for this size db?

Also, I'm a firm believer in searching forums and RTFM (in EP's case - a readme file) --> I've done both.

Over to anyone out there who is willing to help ... (thanks in advance)

[tdiaz]

Originally Posted by ranz

I also can't get EP to work either. THERE ARE NO ERROR MESSAGES.


1. catalog/temp is CHMOD 777

2. I SPLIT THE FILE - the split doesn't work - no file in the /temp dir
3. I MANUALLY SPLIT THE FILE - not even 1 row works!!
4. I DOWNLOADED the EP....txt file and uploaded that WITHOUT ANY MODIFICATIONS - it goes straight back into the EP page - no "thank you, file imported successfully" message or anything
[/quote]

Point for point. Exactly the same problem. My installation did not include a /temp directory in the unzipped version either, not that making one is a big deal, but if it's not included in the distribution then perhaps a step should be added, "Create an empty directory called 'temp' for later use in the 'catalog' folder. CHMOD it to 777.

Originally Posted by ranz

5. the actual php code of EP could do with some error processing.
6. IF it's a time-out issue - surely you can test for this using php (you can) and have it fail before it does anything and say "your time-out is set to xxx --> you need a minimum of yyy to be able to upload more than 100 rows"

This would be handy, but I think figuring out why so many people have problems with it would be time better spent. Of course, it may take some debug reporting points in the code so one could see at what point it's failing or stopping.

Originally Posted by ranz

What if we want a shop with > 20,000 products? is everyone saying that Osc is no good for this size db?

I don't think this is so much an issue as just the PHP importing and typical browser timeouts of anything taking longer than 60 seconds. Since this is being done as a form action. Since it's been figured out that about 300 records take longer than 60 seconds, so split it up for massive importing. Since it's mysql and that is obviously designed with enterprise use in mind I don' think this is an issue. The 300 item import wouldn't be an issue if this were done with a console application instead of a browser form action.

Originally Posted by ranz

Also, I'm a firm believer in searching forums and RTFM (in EP's case - a readme file) --> I've done both.

I really do my best to seek out answers via search engine and forum responses of past questions before even hitting that post button to ask, but with this particular issue, it seemed to be a hot topic with no answer, so I asked again.

I'm not unfamiliar with database concept and the logic behind it, I've been a greater than average power user who used to program in the Apple II days, but not as much since, though I regret not keeping up with it. I've always kinda used out of the box solutions and finally got tired of being tied to a vendor when needing a change made in the database structure, or a report, to have output via web or an invoice print differently, so I'm venturing into OSC with not a lot of experience in PHP, but with the understanding it's sorta similar to general C in some ways, and I'm not totally foriegn to that.

Long term, I'd like to take a stab at making a console app similar to what is available for Win32, for Mac OS X- to work with OSC, in addition to web administration.

My general feelings on Web Administration interfaces is damn near most of them are cheap shots from companies who don't wanna spend the time to put a quality package together. OSC is a very well rounded peice of work and it over all does not fit into the description I quoted above, but with things like the browser timeout when working with large amounts of data, it's pretty obvious that there are bottlenecks that could be overcome, that are not any specific fault of OSC.

Originally Posted by ranz

Over to anyone out there who is willing to help ... (thanks in advance)

Me too, if anyone has any input on this, I'd be thrilled.

Between this and Dynamic MoPics, thats about the only problem I've had with OSSMax at all. Everything else worked as stated right out of the archive.

My server is OS X Server and Client, one copy on each, both have the same identical issues.