Ticket #9644 (closed defect (bug): fixed)

Opened 3 years ago

Last modified 3 years ago

(bug) get_categories

Reported by: arena Owned by: ryan
Priority: high Milestone: 2.8.1
Component: Taxonomy Version: 2.8
Severity: critical Keywords: has-patch
Cc:

Description

$args = array('hierarchical' => false,'depth'=>false,'echo'=>false,'get'=>'all');
$categories = get_categories($args);

returns

Array ( [errors] => Array ( [invalid_taxonomy] => Array ( [0] => Invalid Taxonomy ) ) [error_data] => Array ( ) )

Attachments

9644.diff Download (1.2 KB) - added by ryan 3 years ago.
9644.2.diff Download (519 bytes) - added by Denis-de-Bernardy 3 years ago.

Change History

  • Status changed from new to closed
  • Resolution set to worksforme
  • Severity changed from critical to major

Works for me in r11082

  • Status changed from closed to reopened
  • Resolution worksforme deleted

ryan

i do not see why this bug is related to "Check if not exists and not is_dir before bailing. Props st3ff3n."

comment:3   DD323 years ago

  • Status changed from reopened to closed
  • Resolution set to worksforme

I believe mtekk's post was that as of revision 11082, Its working as expected under trunk.

It works for me under current trunk.

Given the error message, I'd assume theres a plugin conflict; Or theres a corrupt file.

Trac is not for diagnosing individual problems, You're better off on the support forums, and re-opening this if you find any info which suggests it IS a bug in WP(Such as also occuring on a fresh WP Install without any modifications)

comment:4   DD323 years ago

  • Milestone 2.8 deleted
  • Status changed from closed to reopened
  • Resolution worksforme deleted

Reopening this based on forum reports:  http://wordpress.org/support/topic/280256

  • Milestone set to 2.8.1

Same issue as #10160??

Seems a number of themes with a theme options page that uses get_categories fail

 http://wordpress.org/tags/trac9644

 http://themeforest.net/forums/thread/wp-28-compatible/13432

comment:7   ryan3 years ago

Technically, these themes are broken in 2.7.1 as well, but the problem won't be evident unless you're using a custom taxonomies plugin. Maybe we can init the default taxonomies right before loading the theme's functions.php to paper over the issue.

ryan3 years ago

but in this case we'd lose the localization of the taxonomies. uploading a potential fix in a few minutes.

comment:9   ryan3 years ago

I added it after locale is setup. I think that will preserve localization.

However if someone manipulates the locale from functions.php, the taxonomies won't reflect that.

@ryan: yours works too, but doesn't fix #10160.

what I was thinking of is to disable the ability to override the default taxonomies.

nm previous comment. second patch works around the problem by doing this twice:

  • before plugins and themes are loaded
  • on the init hook to enforce localization
  • Keywords has-patch added; needs-patch removed
  • Severity changed from major to critical

making this a blocker, as it's apparently critical to quite a few users.

  • Status changed from reopened to closed
  • Resolution set to fixed

(In [11573]) Register default taxonomies before theme functions are loaded to satisfy themes that don't wait until init to call taxonomy functions. Default taxonomies are registered again during init so that translations are handled correctly. Props Denis-de-Bernardy. fixes #9644 for trunk

(In [11574]) Register default taxonomies before theme functions are loaded to satisfy themes that don't wait until init to call taxonomy functions. Default taxonomies are registered again during init so that translations are handled correctly. Props Denis-de-Bernardy. fixes #9644 for 2.8.1

Tested with French and Spanish translations and with a couple custom taxonomy plugins.

Note: See TracTickets for help on using tickets.