Post Creation Project Database Tables

This column does not hold the ID in your data. It is simply an incremented number starting from 0 for all rows imported. Each CSV file row imported creates a record record and every record has a wtgcsv_id value. The value is added to the post meta created using the record, this is how we make a connection from a post too the record.

A key use of this connection is when opening a post. WordPress CSV Importer can use the wtgcsv_id value in post meta to track down the record and check if the record has been updated since the post was created. If the record has changed in any way, WordPress CSV Importer can initiate an update to that post. This happens before the visitor sees the post so that they see the newly updated post.

This column holds the WordPress post ID created using the record. An example use would be to manually update posts with changed records.

This column is not in full effect as I type this. The plan is to store a posts content in this column before an update is applied to the post. This allows us to easily reverse content updates. We have also considered advanced selling features such as alternative content and statistics helping to determine which version is best when both versions are shown in equal amounts. We would like to automate the plugin to decide for users, which content to show especially where clicks are concerned.

This column will hold a value of 0 or 1, true or false. A zero or false indicates that the the record is not in use or void. Eventually there may be other values found in this column i.e. void. The term void would indicate that the imported row is not suitable and has automatically been made void or the user has applied the status.

Holds time and data when the row was first imported. Mainly for reference.

The date and time when the record was last updated. These values are compared to a posts last update date and time. If the date held in the project table is later than the one held by the post, it triggers the post to be updated with the newer data.

This also indicates when the record was changed but it does not include data import from CSV file. This data value indicates the last time that the plugin changed values in the record i.e. it may change raw values based on rules created by the user. There will eventually be tools for mass changing data also. The reason for indicating these changes in a separate column from wtgcsv_update for reference sake. We have a better idea of why and when a record was updated this way.

This is the date and time when the record was used to update its post (applied to post. This includes the original creation date. This value is also used to determine if an update is required for a post by comparing the data to the posts own date.

If you import multiple CSV files into one table, this column will be created for each file. When a value is put in this column for a row, it indicates that the data for the owning file has been fully imported. If for example you import 3 CSV files into a single table, there would be 3 wtgcsv_filedone columns, each with an appended number on the end. In order for the record to be used to create a post, all three wtgcsv_filedone columns would need to be populated. This tells us that the record is ready to be used. The reason for this measure is because we can only really import one CSV file at a time and so there has to be a way to know when the record is complete. This is just a sample of the complexity in the premium edition and why professionals turn to WordPress CSV Importer when doing very complex data import projects.

This column holds a CSV files “Modified” date. We use it to check if a CSV file row has been updated since a new file was detected. If not we can manually request import from the CSV file so that the records get updated. There is also a chance that rows in a CSV file cannot be used to update their record. I cannot assume that a users data will be perfect, there could be problems in a newer version of the CSV file that did not exist in the earlier versions. The plugin may skip updating a row and so we can pick up on this even once the rest of the CSV files rows have been imported.

All projects currently require at least one project table. This may eventually change to suit users who seek something else so always double check. WordPress CSV Importer will check all of the database tables you select when creating a Post Creation Project. If it finds that there are no tables created by this plugin, it will create one. The new table would only have the said columns mentioned above and users must be able to make a relationship between all tables including the project table. The project table with the special columns listed on this page will allow the tracking of progress, reversal and will eventually aid making advanced relationships between data tables that were never meant to be used together.

WordPress CSV Importer has been designed to rely on project tables. Other plugins do not import data as such. They create posts using data in CSV files, it is WordPress that actually imports the data and places it where it needs to go. Plugins that work in that way, don’t have to do much at all, there is little in their core and WordPress does most of the work. We want to create a premium plugin worth buying and to do that it requires advanced features. Advanced features start with managing and manipulating data before the values are used to create posts. That requires the data to actually be “imported” before creating posts.

Project tables allow us to build relationships between records (also known as rows when in a CSV file), in the project table i.e. some CSV files may not have an ID or product code column. No unique way to bond rows/records and their posts together so that advanced abilities such as updating will actually work properly. Our approach allows us to handle data that do not have a type of ID per row, far better than plugins that do not import to a database table first. This is a fact and the work that goes into making this happen is by far more complex than most premium data imports on sale for WordPress.

The relationship connecting data to existing posts cannot be created between a CSV file and posts, in a plugin that does not allow drip-feeding, without much risk. No database table means the entire CSV file would need to be imported and applied to existing posts all at once. Sure we can backup the database as a precaution, take the website offline and display an “Under Construction” notice. Problem when working with data is you never truly know how long it is going to take, problems always arise especially when trying to do massive amounts of importing, leading to long server processing in a Content Management System (WordPress) that needs to do a lot to create each post. We don’t consider it practical or as safe as doing data import plus post updating gradually, with the aid of a project database table. These tables allow many advanced abilities that help us maintain our blogs without pushing our server to its limit or taking our sites offline i.e. past the 30 second processing limit when importing 200,000 rows and updating 200,000 posts all at once. Some features including being able to detect issues with rows in a CSV file, which are being applied or have been inserted/updated to the project table. We have such features especially for those of you who have no idea of the true quality of your data.