[wp-trac] [WordPress Trac] #46297: Unable to edit specific terms : rest_cannot_assign_term OR 403

[WordPress Trac]

#46297: Unable to edit specific terms : rest_cannot_assign_term OR 403
--------------------------+------------------------------
 Reporter:  enps5         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Taxonomy      |     Version:  4.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by enps5):

 Thank you for your help @boonebgorges, this has helped us to identify the
 origin of the problem, to allow it to never happen again and to act
 retroactively on old taxonomies.

 As you suggested, there is a table wp_sitecategories and the option is
 enabled in wp_sitemeta :

 {{{
 desc wp_sitecategories;
 +-------------------+--------------+------+-----+-------------------+-----------------------------+
 | Field             | Type         | Null | Key | Default           |
 Extra                       |
 +-------------------+--------------+------+-----+-------------------+-----------------------------+
 | cat_ID            | bigint(20)   | NO   | PRI | NULL              |
 auto_increment              |
 | cat_name          | varchar(55)  | NO   |     |                   |
 |
 | category_nicename | varchar(200) | NO   | MUL |                   |
 |
 | last_updated      | timestamp    | NO   | MUL | CURRENT_TIMESTAMP | on
 update CURRENT_TIMESTAMP |
 +-------------------+--------------+------+-----+-------------------+---------------------------

 select count(*) from wp_sitecategories\G
 *************************** 1. row ***************************
 count(*): 267607
 1 row in set (0.00 sec)

 select * from wp_sitemeta where meta_key = 'global_terms_enabled' \G
 *************************** 1. row ***************************
    meta_id: 28769
    site_id: 1
   meta_key: global_terms_enabled
 meta_value: 0
 1 row in set (0.00 sec)


 }}}

 After disabling the global_terms_enabled option it is no longer possible
 to reproduce the shared/duplicate terms bug (procedure to reproduce is
 described in the ticket https://core.trac.wordpress.org/ticket/47535)

 To retroactively process old taxonomies, we ran this small script, which
 uses wp-cli and https://github.com/jjeaton/wp-find-shared-terms :

 {{{
 # Create a list with all blogs
 wp site list --field=url > /tmp/list_sites.txt
 # Check the list created
 for site in $(cat /tmp/list_sites.txt) ; do
         echo "$site :" && wp --allow-root --path=/localdata/www/hypotheses
 shared-terms split --url=$site --verbose
 done

 bash $SCRIPT |& tee -a split_terms.log
 # We found 1095 shared taxonomies
 grep -c -P "^\d" /root/detect_shared_terms.log
 1095

 }}}


 Maybe we should have checked that the table wp_sitecategories did not
 contain any term_id = 0, we had the case on 3 blogs out of 315 where there
 was a split and on 5071 blogs in total. The term_id has 0 has been split
 in the wp_terms table of the corresponding blogs and this has broken the
 display, we could restore it by deleting the category to 0 in base.

 About the "split_routines", I think there were several factors, i see this
 bug: https://core.trac.wordpress.org/ticket/33423
 maybe in addition to this bug, we did not execute the upgrade_db correctly
 in 4.3 & 4.3.1 and so upgrade_420 and upgrade_430 could not launch
 split_all_shared_terms routines.

 Everything seems resolved and in an efficient way, so thank you for your
 help, we remain available if you want more information about our case.
 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46297#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform