The reason there’s a hole is because revision history isn’t a history of SQL changes. Each revision is represented in the database as a post of type revision. For your changes to be shown, an additional revision post would be needed. To do this, you’ll need to update the post via PHP rather than SQL. … Read more
The only things you could clear out like this are transients, temporary options in the database. WP already does this on a cron job, and it’s unlikely to have a big impact. If you don’t mind data loss, revisions might reduce the database size, but that’s highly dependent on what you’ve been doing with the … Read more
I guess the reason is you have not added post title and added post id $my_post = array( ‘post_id’ => 1, ‘post_status’ => ‘pending’, ‘post_type’ => ‘post’ ); Ideally if should be $my_post = array( ‘post_title’ => wp_strip_all_tags( $_POST[‘post_title’] ), ‘post_content’ => $_POST[‘post_content’], ‘post_status’ => ‘publish’, ‘post_author’ => 1, ‘post_category’ => array( 8,39 ), ‘post_type’ … Read more
You’re using $wpdb->where() incorrectly. In your code, $data_array and $data_where are going to be exactly the same, so if we assume that $_POST[‘getval’] is 1, the resulting query will be: UPDATE wp_fes_vendors SET requests=1 WHERE requests=1 You see how that doesn’t make sense? It’s setting the requests column to 1 for all rows where requests … Read more
Try: function vw_postcode_checker_create_db () { global $wpdb; // Create Table Name $table_name = $wpdb->prefix . “vw_postcode_checker”; // Write Query to add table to database if ( $wpdb->get_var(“SHOW TABLES LIKE ‘$table_name'”) != $table_name) { $sql = “CREATE TABLE $table_name ( id INTEGER(10) UNSIGNED AUTO_INCREMENT, postcode varchar(250) DEFAULT ” NOT NULL, area varchar(250) DEFAULT ” NOT NULL, … Read more
Add the autoincrement keyword after `id` int NOT NULL: public static function activate() { global $wpdb; $sql = “CREATE TABLE `{$wpdb->base_prefix}employee` ( `id` int NOT NULL autoincrement, `name` varchar(255) NOT NULL, `dob` date NOT NULL, `gender` int NOT NULL, `email` varchar(255) NOT NULL, `joining_date` date NOT NULL, `address` varchar(255) NOT NULL, `salary_package` int NOT NULL, … Read more
First, I assume you’re referring to columns, not rows. To answer your question, no, the upgrade process will not remove the extra columns from the posts table. That said, WordPress has the wp_postmeta table that should be used to store extra data about posts rather than adding columns to the posts table. I would suggest … Read more
HyperDB lets you split whole tables across different databases but it won’t split a single table. You wouldn’t want that anyway because that means wordpress would have to query multiple databases to find a single post. However, depending on how your site is set up, you might be able to work around that by creating … Read more
Are you sure those aren’t pages, drafts, trashed, revisions or attachments? To make sure that those aren’t such, run the following in phpMyAdmin (Query tab – field “SQL query on database [database name]:”) Adminer In the terminal … and see how many results you get: select * from wp_posts where post_status=”publish”
I would actually advise against doing that. If you create a table for each blog on network activation you’ll start running into scalability issues. Some Multisite networks are small (2-10 sites) and wouldn’t cause too many issues. But larger networks (1000+ sites) would add a lot to the database if they added their plugin. Instead, … Read more