CPTs should be in a plugin, template files should be in a theme. It does not matter that moving to another theme means that the CPTs will be displayed using index.php and single.php, the point is that there will be no data loss, which is the main point here.
Allthough i agree these things should be in plugins, i’ve seen this incorrect statement too many times.
Wheither you put custom post types into a plugin or directly in the theme’s functions.php file – data is always stored in the database no matter what file is registering the post type.
The data is not lost when switching theme – only thing is the post type is not registered so the data won’t be accessible through the admin.
It’s just a technicality i know But it’s not about data loss – it’s about data access ( inside the admin panel )
I even think there’s a higher chance you lose custom post type data when it’s registered by a plugin – because a plugin could have some deactivate- or delete action on it which deletes his data when deactivating or deleting the plugin.
BUT – nonetheless: It should be in a plugin because this way most functionality keep intact while switching theme.
Thanks for the heads up! I will keep an eye on it
I found the following modification to the Kloon library:https://github.com/woothemes/woocommerce/issues/6174
Now it all seems to work
Yes i have.
I have it working now with a custom call using the Kloon library.
$product = array( 'sku' => '100001', 'title' => 'Superduper product', 'type' => 'simple', 'regular_price' => '21.50', 'description' => 'Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas.', 'short_description' => 'Short description for product', 'categories' => array( 'testcat', anothercat' ) ); return $this->_make_api_call( 'products', array( 'product' => $product ), 'POST' );
It is creating the product well – but i still get the following error returned:
Warning: rawurldecode() expects parameter 1 to be string, array given in class-wc-api-client.php on line 465 stdClass Object ( [errors] => Array (  => stdClass Object ( [code] => 201 [message] => cURL HTTP error 201 ) ) )
probably because this library isn’t updated for v2 yet or something..
Any suggestions? Or maybe some other easy PHP auth rest client to use for api calls…
I’m trying to figure out how to create a decent API call with PHP to create a product.
I’ve used the client ( https://github.com/kloon/WooCommerce-REST-API-Client-Library ) before, but it does not yet support POST/PUT methods.
But i figured this should be easy to add for myself – but no luck yet..
Anyone got some pointers?
We’re actually very much okay with authors promoting their items. The issue arises when authors are promoting the inclusion of something additional (beyond the Market item itself) on the condition of purchasing the item. (ie. if you buy my item, you also get…)
Seems in this case the author(s) didn’t place such promotion on the item page here on TF – so, ( just to be clear ) if they place something like that on their own website then there’s no problem right? If you for example say: “Get this goodie for free with your TF purchase code”
Whether you provide additional support or some download goodie makes no difference.
This is strange.
If they promote their TF item on their own or another site then what’s the problem? They don’t promote another site or freebies here on TF, so they do it right if you ask me.
I mean, what about all those referer sites? Practically the same. And so what if they want to offer freebies from their own site?
I think it’s not right when TF/Envato interferes with non TF content.
Ofcourse we can – why not? Premium plugins are doing it so why can’t we in a premium theme..
Well if it was up to me all that data being send from apps on your phone to the app store and app copmanies should stop immediatly – but who am i to say in such a big business world – stoppid that is already to late and also most people just don’t care.
I don’t know if Envato has any rules on tracking item-user information about the used settings of a theme or something.
You’re right about the survey – best guess is to put in an option which askes the theme/plugin users if they want to help keeping track of some data: ‘Yes (you can always turn this of inside the settings)’ – ‘No, leave me alone’
If choosen yes: Do your magic.
That would be a totaly wrong thing to do automatically without asking.
What you could do, like some plugins do, is ask for permission to send some ( and explain what ) information to the theme author – but i think most of the users will disaggree.
A Analytics code would be a very bad idea, since you also get detailed ‘private’ analytics information from other sites – i don’t think users like that.
Maybe a way is to create a user database and send an email to ask your theme users to fill in a online survey ( the way WordPress does from time to time ).
If i speak as a user: i always disable all kinds of tracking for plugins etc.