I manage a new WPMU installation clone but I want clear a part of subdomains.
When I delete a suddomain from Wordpress MU (clone), all tables get dropped but all the tables where a plugin need write is still here.
Then there is SQL command like (to delete all tables in one shot):
DELETE from 'wp_ID' to 'wp_ID'
but delete all primary table and all sub-table like wp_ID_plugin
Because I have some residual table after maybe 10 or 15 tables with ID from plugins.
I ask this because I have a Wordpress MU with over 600 website and I split it into two wordpress MU.
Edit /
I choose another way to try to clean database. I found a sample code
Delete Extra Plugin Tables When a Site Is Deleted in WordPress Multisite
And adapt array for my specific tables
$plugin_tables = array( 'statistics_useronline', 'statistics_visit', 'statistics_visitor', 'csp3_subscribers', 'ewwwio_images', 'mappress_maps', 'mappress_posts', 'revslider_css', 'revslider_layer_animations', 'revslider_navigations', 'revslider_sliders', 'revslider_slides', 'revslider_static_slides', 'sendpress_autoresponders', 'sendpress_list_subscribers', 'sendpress_queue', 'sendpress_subscribers', 'sendpress_subscribers_meta', 'sendpress_subscribers_status', 'sendpress_subscribers_tracker', 'sendpress_subscribers_url', 'sendpress_url', 'statistics_exclusions', 'statistics_historical', 'statistics_pages', 'statistics_search', 'statistics_useronline', 'statistics_visit', 'statistics_visitor', 'yoast_seo_links', 'yoast_seo_meta' );
I will manage this next week, seems work over "test tables"
Related
Does anyone know how to separate wp_options from two WordPress while sharing post data?
I’m now creating websites both personal and my company’s one using WordPress. I realized that it will be efficient if I could share post data on both websites which have different web design.
Although I’ve already tried sharing MySQL and it works, it also shared title name which stored in wp_options as well. That means if I changed site name of the personal website, it also effects company’s one. This is not only about site name but other settings in wp_options.
I also couldn't find how to do this from official WordPress website below.
https://codex.wordpress.org/Editing_wp-config.php
Yes, we can separate wp_options for two WordPress while sharing post data
Install 2 website with single db ( 2 copies ).
Create new table in you'rs db. Call it wp_options2 and copy everithing from wp_options inside new table
in seccond install in wp-config.php, before if ( !defined('ABSPATH') ) add define( 'M7_OPTIONS_TABLE', 'wp_options2' );
in seccond install go to wp-includes/wp-db.php on line 951 and add code:
if ( isset( $tables['options'] ) && defined( 'M7_OPTIONS_TABLE' ) )
$tables['options'] = M7_OPTIONS_TABLE;
( these code should be added in public function tables function, before if ( isset( $tables['users'] ) && defined( 'CUSTOM_USER_TABLE' ) ) )
Now you should be able to change theme, plugins atc. for seccond theme, but all posts, taxonomies atc. will be dubbled in both websites ( wich is bad for seo bdw. )
if on seccond install you'll have some problems with links, add
define('WP_HOME','http://seccond_website.com');
define('WP_SITEURL','http://seccond_website.com');
in your wp-config.php file .....
I am aware of syncdb and makemigrations, but we are restricted to do that in production environment.
We recently had couple of tables created on production. As expected, tables were not visible on admin for any user.
Post that, we had below 2 queries executed manually on production sql (i ran migration on my local and did show create table query to fetch raw sql)
django_content_type
INSERT INTO django_content_type(name, app_label, model)
values ('linked_urls',"urls", 'linked_urls');
auth_permission
INSERT INTO auth_permission (name, content_type_id, codename)
values
('Can add linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'add_linked_urls'),
('Can change linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'change_linked_urls'),
('Can delete linked_urls Table', (SELECT id FROM django_content_type where model='linked_urls' limit 1) ,'delete_linked_urls');
Now this model is visible under super-user and is able to grant access to staff users as well, but staff users cant see it.
Is there any table entry that needs to be entered in it?
Or is there any other way to do a solve this problem without syncdb, migrations?
We recently had couple of tables created on production.
I can read what you wrote there in two ways.
First way: you created tables with SQL statements, for which there are no corresponding models in Django. If this is the case, no amount of fiddling with content types and permissions that will make Django suddenly use the tables. You need to create models for the tables. Maybe they'll be unmanaged, but they need to exist.
Second way: the corresponding models in Django do exist, you just manually created tables for them, so that's not a problem. What I'd do in this case is run the following code, explanations follow after the code:
from django.contrib.contenttypes.management import update_contenttypes
from django.apps import apps as configured_apps
from django.contrib.auth.management import create_permissions
for app in configured_apps.get_app_configs():
update_contenttypes(app, interactive=True, verbosity=0)
for app in configured_apps.get_app_configs():
create_permissions(app, verbosity=0)
What the code above does is essentially perform the work that Django performs after it runs migrations. When the migration occurs, Django just creates tables as needed, then when it is done, it calls update_contenttypes, which scans the table associated with the models defined in the project and adds to the django_content_type table whatever needs to be added. Then it calls create_permissions to update auth_permissions with the add/change/delete permissions that need adding. I've used the code above to force permissions to be created early during a migration. It is useful if I have a data migration, for instance, that creates groups that need to refer to the new permissions.
So, finally i had a solution.I did lot of debugging on django and apparanetly below function (at django.contrib.auth.backends) does the job for providing permissions.
def _get_permissions(self, user_obj, obj, from_name):
"""
Returns the permissions of `user_obj` from `from_name`. `from_name` can
be either "group" or "user" to return permissions from
`_get_group_permissions` or `_get_user_permissions` respectively.
"""
if not user_obj.is_active or user_obj.is_anonymous() or obj is not None:
return set()
perm_cache_name = '_%s_perm_cache' % from_name
if not hasattr(user_obj, perm_cache_name):
if user_obj.is_superuser:
perms = Permission.objects.all()
else:
perms = getattr(self, '_get_%s_permissions' % from_name)(user_obj)
perms = perms.values_list('content_type__app_label', 'codename').order_by()
setattr(user_obj, perm_cache_name, set("%s.%s" % (ct, name) for ct, name in perms))
return getattr(user_obj, perm_cache_name)
So what was the issue?
Issue lied in this query :
INSERT INTO django_content_type(name, app_label, model)
values ('linked_urls',"urls", 'linked_urls');
looks fine initially but actual query executed was :
--# notice the caps case here - it looked so trivial, i didn't even bothered to look into it untill i realised what was happening internally
INSERT INTO django_content_type(name, app_label, model)
values ('Linked_Urls',"urls", 'Linked_Urls');
So django, internally, when doing migrate, ensures everything is migrated in lower case - and this was the problem!!
I had a separate query executed to lower case all the previous inserts and voila!
Have in my content in 600 sites links + linkword that I want delete per Mysql command. I want delete the whole "a href" tag include the linked content. But not from 2 special user IDs
all datas in a mysql table called xx_content, the columns called xx_fulltext (theres the links), and xx_userid
I try this with the command
UPDATE xx_content SET xx_fulltext = REPLACE(xx_fulltext, 'a href', '');
but thats didn run
I have a MySQL DB with multiple tables and views on those tables. A view limits what can be seen to a single customer's data (create view ... where customer_id = X). The Catalyst app will be talking to these views, not to the actual tables. The only difference between the view's columns and the underlying tables' ones is that the view lacks the customer_id column (i.e. to the application it seems like the current customer is the only one in the system).
The problem is, I cannot use DBIC Schema Loader to load the schema from the views, as they lack all the relations and keys. I have to load the schema from the base tables and then use it on the views. The problems is, I cannot get rid of that customer_id column. I need to get rid of it, because it is not present in the view that the application will be talking with.
I ended up using the filter_generated_code option to strip the unneeded bits away from the generated code, but then I get the following error during generation:
DBIx::Class::Schema::Loader::make_schema_at(): No such column customer_id
at /opt/merp/perl/lib/perl5/Catalyst/Helper/Model/DBIC/Schema.pm line 635
How can I have the loader skip certain columns at load time?
I'm not sure how you can get the loader to skip columns at load time, but you can remove them after load. For example, you can add something like this to any class which needs a column removed:
__PACKAGE__->remove_column('customer_id');
I'm not sure if there is an option for that in DBIC::Schema::Loader, the docs will tell you. If there isn't just generate the schema and then remove the column definition.
But besides that you seem to be missing a major feature of DBIC: ResultSet chaining.
If you're using e.g. Catalyst you'd have an action that filters your ResultSet on the stash based on the customer id and all chained sub actions would only ever see the allowed rows.
I ended up just leaving the column for what it is, so it is visible to the application code. The DB views and triggers ensure the application can only insert and select the currently set customer id. The only trick I employed was using filter_generated_code to replace the underlying table name with the view name (just stripping a leading underscore). This way I now have a script that does a show tables, filters out the views, dumps the structure into the DBIC classes, replacing the table name with the view name, looking somewhat like this:
exclude=`mysql -u user -ppassword -D db --execute='show tables' \
--silent --skip-column-names | egrep "^_" | sed "s/^_//g" | \
sed ':a;N;$!ba;s/\n/|/g'`
perl script/proj_create.pl model DB DBIC::Schema Proj::Schema \
create=static components=TimeStamp filter_generated_code=\
'sub { my ($type,$class,$text) = #_; $text =~ s/([<"])_/$1/g; return $text; } ' \
exclude="^($exclude)$" dbi:mysql:db 'user' 'password' quote_names=1 '{AutoCommit => 1}'
It appears that somehow in the past, WordPress saved multiple redundant post_meta for post revisions which are no longer in the database.
As a result, I have a ton of post_meta that does nothing and is tied to posts that no longer exist.
Does anyone know how to remove this data from phpMyAdmin with a SQL query?
You can run a mysql query like this; WordPress › Support » SQL Query to delete orphans wp_postmeta, but might be easier and safer to use a plugin like WordPress › Mass Custom Fields Manager « WordPress Plugins or WordPress › Custom Field Taxonomies « WordPress Plugins
"Optimize Database" is the one I use. Setup is very quick and easy. It runs in the background daily cleaning out post-meta orphans, things you have trashed, and useless old "revisions".
This has been explained here in full.
Remove Unnecessary WP Postmeta
All you have to do is add the following in your theme functions.php file
function delete_useless_post_meta() {
global $wpdb;
$table = $wpdb->prefix.'postmeta';
$wpdb->delete ($table, array('meta_key' => '_edit_last'));
$wpdb->delete ($table, array('meta_key' => '_edit_lock'));
$wpdb->delete ($table, array('meta_key' => '_wp_old_slug')); }
add_action('wp_logout','delete_useless_post_meta');