Category Archives: Hacking

Someone at some point may notice that CSV 2 POST has three CSV file upload scripts, that are all the same. Well as I type this they are. The plan is to adapt each of them for different purpose. It is also handy for hacking because we can keep an original script.

Free edition will obviously end up with something more simple compared to paid edition also. So this is the reason for duplicate code, which is not normally the done thing.

The ECI screen for paid and free editions each have their own script. The sandbox areas CSV file upload form uses a different script also. That one will become the most advanced and will be modified to allow other file types. The general form submission processing for the sandbox area will actually process other feed types being submitted for the initial setup such as URL or FTP etc.

For now they are just duplicate code!

The csv2post_log table was added 4th March 2013 and replaces log files. The log table is a multi-purpose table with the different purposes sharing the same columns but for totally different reasons. The column named “type” must be used to group rows by the type value. The reason for the multi-purpose approach is to reduce the number of tables installed by CSV 2 POST and because each purpose in play could have its own table but would probably still require logging i.e. if an item such as a post was being flagged it would also be logged as having being flagged. Instead we can do a single INSERT query and in many cases use the data in a row as if it was one type or the other i.e. all flags could be treated as logs and listed on the interface along with rows with the “log” type.

Columns

Some of the columns used for logging allow us to trace users steps but they are also part of our user experience program. The data allows us to build statistics regarding what screens are visited and what panels are used.

Without a doubt CSV 2 POST is the most complex plugin of its kind. One area that has taking endless hours to perfect is automatic post updating. During the last 2-3 months (Oct-Dec 2012) we found ourselves creating a smart system for post updating that updates posts in response to three different changes. We refer to these as Update Reasons rather than triggers simply because the term ‘trigger’ is being used elsewhere. It’s no big deal really.

What is important to understand is that posts are updated when one of three reasons exist and I will explain each reason below. I should also mention before I continue that this applies to the paid edition only.

1. Changed/Updated Record

Straight away this causes many users confusion because CSV 2 POST imports data to a temporary database table, created by CSV 2 POST automatically, prior to the creation of posts or anything else. This is unique to CSV 2 POST. Our approach is required for advanced features no other plugin provide and we strongly feel this approach is far more fitting for a professional or business.

So to be clear. CSV file rows, are imported and become database records. From there we can do lots of cool things. One thing we can do is update those records, getting data from CSV file into our database, but not actually changing posts. ‘Why do that?’ you may ask. Well it is for many reasons, a long list of reasons but overall it allows us to ‘play around’ with the data before it is make public. I’ll let your imagination come up with some ideas, there are no limits to the data manipulation we can do.

If we update existing records by importing a newer CSV file than the original, this will trigger post updating providing your project is configured for updating and the schedule is setup also. Our auto-blogging plugin is designed for every user and many users do not want every post updated instantly. So by default things happen slowly, in a manner often referred to as drip-feeding or maybe we can call this drip-updating!

The schedule script will query any database records that have changed since they were used to created or update a post. There is a column holding the date and time values of when data was last applied. Comparing that date and time to the one for when the record was changed allows our script to determine what records can be used. It’s actually very simple and the original approach. However it is not enough, not for the best CSV import plugin on WordPress!

Read on to learn and understand the other two post updating reasons that are just as important as the above.

2. Meta Key: csv2post_outdated

All post from now on (since version 6.7.2) will have a new meta value named ‘csv2post_outdated’. The value for this meta will be yes or no. Yes meaning the post is out-of-date and no, well you get the point.

The creation of this new meta was a sudden thought of my own and is a little hint to a larger plan we have for an API. By having this meta value in place any script, if it be in a theme or another plugin, can trigger a post to be updated. Considering another plugin changing the data originally imported using CSV 2 POST. A shopping cart plugin can share the same data with CSV 2 POST, both plugins can be used to manage the data. However the shopping cart plugin would need to update the records changed data and time.

Pretty much along the lines of the first method explained above however by changing the csv2post_outdated value we can flag posts directly. An interface will be created which lists all out-of-date posts. There is no other practical way of being able to flag posts. The flexibility in this is endless i.e. users who do want automatic post updating in place but want to know that posts are out of date then manually update them or even just delete them. How the csv2post_outdated status is interpreted could also be changed to suit a developer i.e. they could use it to indicate that a post is overdue for an update with certain criteria in use to determine that it could or should have been updated.

3. Project Configuration Changed

Whenever the user changes settings in a project a date and time is stored. That date and time is compared to the update date and time stored in a meta value for csv2post_updated. To make this work we also have a value that acts like a switch. The switch is only switched off when CSV 2 POST cannot find any posts that have not been updated since the projects configuration was changed. When the switch is on, CSV 2 POST can quickly determine if any projects have posts requiring updating.

That is the technical workings of it. In short changing a projects configuration is a reason for posts to start being updated but only if the plugins settings allow it. As with everything there are settings to stop or start these features.

I should also mention there are some things in project configuration that do not cause the update i.e. categories, permalink. That can be changed on request. We simply want to avoid users making changes to parts of posts that are normally kept as they.

The Scripts Order

The above post update reasons are typed in order that they happen within our script. This is important to know because all of our automated functions have limits in place, they need to end somewhere right! It means the first update reason could keep the plugin busy and it never really arrives at the other two update reasons within the script, meaning the checks are not done for those. Limits would need to be raised and possibly some customizing if anyone wanted CSV 2 POST to do a lot more processing than we have designed it to do. we have designed it for the average server with 30 second limit on processing.

There are currently around six meta values stored with each post by default. You may know them as custom fields. Most of them provide advanced abilities and are in the paid edition. The thinking, planning, development and support that goes into the scripts using these meta values are endless.

I expect more to be added in future so if you spot any and we’ve not updated this page please let us know. Users can also configure the plugin so that it adds every data value from each of your CSV file columns into meta fields but we won’t cover those here.

csv2post_last_update

The meta value for this key is the standard date and time. This value is required to support themes that use the WordPress post publish date for something other than, well the publish date. The csv2post_last_update value tells us when the post was last updated, by CSV 2 POST, not by any other method. So we know when the plugin last dealt with this post and applied any changes in the project etc.

csv2post_outdated

This was added in November 2012 to improve automatic post updating after changes to the posts project are made. The value for this meta is either “yes” or “no”. Is the post outdated? If it is then the plugin can locate such a post using this meta and update the post (paid edition only by the way). My plan is to change the no too yes when changes are made to project settings. Essentially we would mass change this value. Overall the purpose is to allow us to do a search for these post, created by any number of projects, without needing project data. Querying project data first and not even knowing if we need it yet (script does not know if posts require updating) can be a lot of work. This care to provide the best efficiency begins in the schedule system, which is where the csv2post_outdated meta value is queried and only once a post is located with a “yes” do we then get that posts project array.

csv2post_totalcloaks

This is related to URL cloaking. CSV 2 POST premium edition allows any number of cloaks to be used, that is any number of URL to be cloaked. We can cloak the same URL many times using the same cloak that is simple. We can cloak multiple different URL and each get their own cloak. To manage this we need to increment a sort of ID per cloak within a post and to do that we need a count of total cloaks used. The meta keys for original URL values which are stored in meta also, cannot be the same. They must be unique so we know which cloak should be forwarded to which URL. That requires the increment value. csv2post_totalcloaks is called during the cloaking procedure during post creation. We simply increase the value by one each time we use it.

csv2post_cloak_NUMBER

A better example would be csv2post_cloak_2 or csv2post_cloak_3, if the post had three or more cloaked URL. This meta key is for a value that holds the URL. The number can also be found in the cloak and is extracted in order to retrieve the original URL during the forwarding procedure.

csv2post_project_code

This is the unique code of the project which created the post. We use this to query the project data using csv2post_get_projectarray($project_code). At some point it may be updated to csv2post_get_option_projectarray().

Do not ever manually change this value unless you are an advanced user. You may change it to another project code which I refer to as project post adoption. However there are possible complications where the posts ID may exist in the original project, a different job table and other advanced things to consider first.

csv2post_record_id

This is the ID of the record used to create the post. It is an auto incremented value in the database table and for most users it will be a Data Import Job table which is a table created by the plugin. Advanced users may use other tables, not created by CSV 2 POST but in all cases the unique record ID must be stored in this meta. This allows us to query the record when opening the post and check the update status then actually update the post using the correct record.

csv2post_template

This holds a post ID, specifically a content template post ID. CSV 2 POST stores content templates as a custom post type. Providing users do not delete that template, we can use this ID value to query the posts template and determine if the template has been updated since the post was created. If the template has changed we can initiate updating. This is not the preferred approach but is a secondary approach to applying template changes. The primary is the csv2post_outdated meta value which acts as a first step, actually determining a post is out of date in some way in relation to project settings. Templates are considered a part of a projects settings. However we can bypass the use of csv2post_outdated and do all required queries for a single post all at once. Fine sometimes but it could also be a lot of work for nothing as the result may be that all posts in question do not need to be updated at all.

csv2post_textspincycle_SPINNERNAME

Creating a spinner (text spin) and using cycling rather than random value will add a new meta value with the above key. The value is used to track the last value used and perform a cycle by selecting the next value in the list created by user. A full example from my current testing on this new meta key is csv2post_textspincycle_test9. The name giving to my spinner was Test 9, this name is cleaned for using in the meta key which will been seen on the Edit Post screen as a custom field. Added to the plugin 18th January 2012.

csv2post_textspindelay_SPINNERNAME

This meta is used to enforce a delay between spins. The value stored is the number of seconds to be delayed. A full example would be csv2post_textspindelay_test9.

csv2post_textspintime_SPINNERNAME

This meta holds the last spin time. Adding the delay to be enforced to the last time a spin was done for the short-code allows us to determine if the short-code is due for another spin or not. A full example is csv2post_textspintime_test9.