ergontech / ergontech_tabular Goto Github PK

PHP 100.00%

ergontech_tabular's Introduction

`Ergontech_Tabular` Data Processor

ErgonTech_Tabular (sometimes refered to as "tabular" for the sake of brevity) is a Magento 1.x module designed to make tabular data processing easier. It provides a framework around which data import, export, and more can be built.

Installation

It is recommended to install ErgonTech_Tabular with composer. composer require ergontech/tabular-magento. Currently, there is no repository where Ergontech_Tabular can be found, so it must be added as a VCS repo. As it depends upon ergontech/tabular-core, that repository should also be added.

Components

Tabular is built using the following:

Profile: Represents a complete action, such as Import products into Magento from Google Sheet with ID x. Accepts a Processor and adds the necessary Steps to it to complete the action.
Step: A discrete action, such as create all nonexistent root categories found in the Rows (example)
Rows and Processor are described in Tabular's core

Usage

Out of the box, Tabular provides the following functionality:

Loading data from Google Sheets
Importing products, categories, and product categorization using AvS_FastSimpleImport
Importing attributes
Transforming column headers to match input requirements

Adding Functionality

The main entry points for functionality are profile type classes, profile type XML configuration, and Row Transforms.

Module Configuration

This module provides the following configuration values:

tabular/general/enabled A yes/no value. Enables/disables the entire module
tabular/google_api/type See ErgonTech\Tabular\Model_Source_Google_Api_Type
- API keys only have access to public sheets, whereas a Service Account can access private sheets
tabular/google_api/api_key Authentication credentials for access. Use the correct authentication data corresponding to the chosen type.

Transform Helpers

Note: The Header Transform functionality of Tabular is deprecated and will be removed in the future!

Currently, most profile types have both a ErgonTech\Tabular\HeaderTransformStep and ErgonTech\Tabular\RowTransformStep(see their contents in ergontech/tabular-core). As of the pre-1.0 release phase, these both accept just one callback.

Example

Most Transform Helpers are picked as an "extra profile data" option. Existing Profile Types use a callback node in the option to specify the method to be called:

<!-- config/global/ergontech/tabular/profile/type/[type] -->
<extra>
    <transform_option>
        <input>select</input>
        <label>Transform Option</label>
        <options>
            <option_1>
                <label>First</label>
                <callback>ClassName_Of_Helper_Class::rowTransformMethodName</callback>
            </option_1>
            <option_2>
                <label>Second</label>
                <callback>ClassName_Of_Helper_Class::otherRowTransformMethodName</callback>
            </option_2>
        </options>
    </transform_option>
</extra>

For an example of how to retrieve the callback configuration and turn it into a valid callable, see ErgonTech\Tabular\Helper_RowTransforms::getRowTransformCallbackForProfile

ergontech_tabular's People

Contributors

Watchers

Forkers

icecubenz-open-mage

ergontech_tabular's Issues

Tabular should have "debug" and "production" logging modes

Primarily, this would influence how much information is shown to admins during the running of a profile instance

Document Product Categorization Import

Allow generic columns to use "entity specification" format

By prefixing a column name with entity:, we can identify columns which specify an entity by alternate means.

A single widget can't have two layout updates in a single import

Problem
Widget layouts are merged with the in-database layout updates during row transformation. This happens before any new layouts are saved to the database, so if a widget has two updates, the later one will overwrite the first.

Solution

We can potentially create a Merge Step That combines multiple rows that have the same value for a given column (in this case, widget ID)
Others?

Widget package/theme should be automatically determined

Using the currently active store, we can determine which theme is active. For each active theme discovered using this technique, we can create the correct number of new widgets and be sure that they're active.

When possible, Import profiles should merge with existing application data

Tracking:

Long-running imports can appear to "break" if the webserver times out

Problem

If the hosting server (Apache, Nginx, or others) reaches its time limit, a 503 error will generally be triggered. This doesn't indicate that the import itself failed, but it renders those with admin-level access incapable of determining if the profile has successfully completed.

Solution

Switch to an asynchronous "checker" that polls for completion of the profile.

Import the "Banner Container" data
Edit a newly imported "Banner Container" widget, adding a new layout update
Re-import the "Banner Container" data
Check to see if the edited banner from step 2 still has its layout update... It doesn't, which is the reason for this issue being created.

here's the module info:

pool	module	version	status
community	ErgonTech_Tabular	0.1.0	active
local	Lfi_Tabular	0.1.0	active

here's what's in vendor/installed.json:

"packageName": "ergontech\/tabular-magento", "version": "0.19.2.0-8f1a8e260a4bcd5d64d53c6d34361398d24a7468",

Document Category Import

Fast Simple Import Does Not Sufficiently Support Category Import

Issues

Clearing fields

fastsimpleimport/general/symbol_for_clear_field is only used by AvS_FastSimpleImport_Model_Import_Entity_Product
Category import uses AvS_FastSimpleImport_Model_Import_Entity_Category.
...which validates with Mage_ImportExport_Model_Import_Entity_Abstract
Eventually, the product import calls _filterRowData, which checks for the ignore and clear symbols.