EasyPopulate 4.0 Support Thread

[shrimp-gumbo-mmmhhh]

Thank you! Will pull from there.

[shrimp-gumbo-mmmhhh]

Just an update. Changed Specials Price to Null and the other error messages I received are gone. Works Great!

Updated records: 467
New Imported records: 35726
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 152789664
Memory Peak: 153206360
Execution Time: 574 seconds.

Would I be able to have these records load in more than just a second layer directory structure? Meaning could I have a main> posters> super heros> batman and have all those categories created on the load?

Thank you!

[mc12345678]

Just an update. Changed Specials Price to Null and the other error messages I received are gone. Works Great!

Updated records: 467
New Imported records: 35726
Errors Detected: 0
Warnings Detected: 0
Memory Usage: 152789664
Memory Peak: 153206360
Execution Time: 574 seconds.

Would I be able to have these records load in more than just a second layer directory structure? Meaning could I have a main> posters> super heros> batman and have all those categories created on the load?

Thank you!

If your question is: is it possible to upload a product to a category structure that doesn't already exist and if so, does it matter how deep the category structure is? Then the answer is yes it is possible and no it doesn't really matter how deep. I mean, I'm sure there is some super long text iimitation...

For your category structure, the field: v_category_name_1
Would contain: main^posters^super heroes^batman if the first category is called main, a sub-category off of there being posters that has a sub-category of super heroes that has a sub-category of batman. Now.... NOTE capitalization, extra spaces and any other characters between each carat (^) are used in evaluating the category relationship. So Batman is different from batman from BATMAN. This is something covered in the readme.

Note also that when a category is created it has an empty description until the associated category data is imported.

[shrimp-gumbo-mmmhhh]

I have found a couple of issues.


1) If not able to insert into the products table then a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products issues in the outcome note and noting file to look at.
2) If not able to insert into the products_description then the record should be deleted from products and a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products_description issues in the outcome note and noting file to look at.
3) If not able to insert into the meta_tags_products_description is not able to be inserted into then a csv file should be created of items not loaded meta_tags to be worked on. There should also be a note noting number of meta_tag issues in the outcome note and noting file to look at.

Thank you!

[mc12345678]

I have found a couple of issues.


1) If not able to insert into the products table then a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products issues in the outcome note and noting file to look at.
2) If not able to insert into the products_description then the record should be deleted from products and a csv file should be created of items that were not able to be inserted. There should also be a note noting number of products_description issues in the outcome note and noting file to look at.
3) If not able to insert into the meta_tags_products_description is not able to be inserted into then a csv file should be created of items not loaded meta_tags to be worked on. There should also be a note noting number of meta_tag issues in the outcome note and noting file to look at.

Thank you!

Did you happen to scroll down the screen after performing an import?

To what file(s) are you referring when stating "noting file to look at"? At the completion of each import, there is some level of information provided. If an "insert" fails, that basically is a problem with the data that has been provided which for the most part likely can not be identified as "successful" or flagged for failure... Meaning, one may have to identify what has been successful to identify what didn't work.

As far some of the processes, it is possible that a message is not provided for one or another issues, for example I know that on a product import where products_model is the primary key, if the products_model field for a row is blank, there is no notification about any issue... Is it a problem? I say no, but that's because an empty products_model in that situation is expected and supposed to be skipped... I state some of that to try to further identify the expectational differences between early and experienced users.

[shrimp-gumbo-mmmhhh]

Did you happen to scroll down the screen after performing an import?

To what file(s) are you referring when stating "noting file to look at"? At the completion of each import, there is some level of information provided. If an "insert" fails, that basically is a problem with the data that has been provided which for the most part likely can not be identified as "successful" or flagged for failure... Meaning, one may have to identify what has been successful to identify what didn't work.

As far some of the processes, it is possible that a message is not provided for one or another issues, for example I know that on a product import where products_model is the primary key, if the products_model field for a row is blank, there is no notification about any issue... Is it a problem? I say no, but that's because an empty products_model in that situation is expected and supposed to be skipped... I state some of that to try to further identify the expectational differences between early and experienced users.

Thanks for your work on this. I realize this is not a paid job and these are just my suggestions for whosoever may want to update this module to make it more excellent.

Hello, yes I did scroll down the screen but this should really be spit out into a file with success and fail notices for each product.

"noting file to look at" if there was a file that contained those errors (it does not currently exists).

Hmmm... you cannot test to see if a sql insert was successful or not? Sorry, so easy to do with languages I have worked with just thought it would be easy in php also.

Thank you for having this working for us currently!

[mc12345678]

Thanks for your work on this. I realize this is not a paid job and these are just my suggestions for whosoever may want to update this module to make it more excellent.

Hello, yes I did scroll down the screen but this should really be spit out into a file with success and fail notices for each product.

"noting file to look at" if there was a file that contained those errors (it does not currently exists).

Hmmm... you cannot test to see if a sql insert was successful or not? Sorry, so easy to do with languages I have worked with just thought it would be easy in php also.

Thank you for having this working for us currently!

What is the setting you have under configuration->Easy Populate 4->'Debug Logging'? Has it been changed from the default of true?

If it is still set to true, then look at your list of files under 'This contains any other file. They will be processed like a full data file.' (The word They changes to this if there is only one file)

If there were "sql" errors while importing the data then there should be a file "ep_debug_log.txt" in that list. In that file is the query/queries that caused errors. Based on the associated information, the issue(s) should be locatable.

As far as logging the text that appears below the list of files, that is something that can be done using the EP4 function: write_debug_log_4($string) where $string is the text to be logged into the debug log.

So for example in admin/easypopulate_4.php towards the end where:
echo $display_output;
is present, then could add:

write_debug_log_4($display_output);

If want to make it dependent on the debug logging setting from above, then:

      if (EASYPOPULATE_4_CONFIG_DEBUG_LOGGING === 'true') {
        write_debug_log_4($display_output);
      }

May also then want to incorporate the 'specials' data within the area below that with:

      if (strlen($specials_print) > strlen(EASYPOPULATE_4_SPECIALS_HEADING)) {
        echo '<br />' . $specials_print . EASYPOPULATE_4_SPECIALS_FOOTER; // specials summary
        if ((EASYPOPULATE_4_CONFIG_DEBUG_LOGGING === 'true') {
          write_debug_log_4($specials_print . EASYPOPULATE_4_SPECIALS_FOOTER);
        }
      }

Remember this is open source so you can do with it what you will and while it has been made available for free download/use, it doesn't mean that there hasn't been some sort of funding by someone to someone at some time. Thankfully Chad Deruski did an outstanding job many years ago with development of so many features and options. As I understand it was developed to support his line of work and then at some point made available for others. He still makes an appearance once in a while.

Note though that you will need to clear that debug file periodically to prevent eating drive space.

Oh and as far as "testing" the SQL, sure two additional lines and some other potential "switch" could be added to the query in the extra_functions file, to perform a transaction that gets reverted, or explained, or an alternate store could be used/tested rather than one's live store (this is a preferred situation so that zero damage is done to one's live store).