Endless loop on admin side

First of all, thank you for your donation!

Custom Posts can’t be the problem, because those are not listed in the DW options. But it might point into the right direction. Do you have many taxonomies in a hierarchy?

Yes, I do have 8 custom taxonomies:

1. Availability – 3 terms
2. Difficulty – 3 terms
3. Lesson subject – 413 terms (hierarchical)
4. Topic – 570 terms (not-hierarchical)
5. Colliection – not currently being used
6. Seminar widget group – 84 terms
7. Course widget group – 25 terms
8. Case study widget group – 12 terms

In terms of custom post types:

1. Courses – hierarchical – 720 posts
2. Seminars – hierarchical – 440 posts
3. Case Studies – hierarchical – 124 posts
4. Live Answers – not hierarchical – 836 posts
5. Events – not hierarchical – 150 posts

I’m suspecting that 413 hierarchical terms might hit you into problems hiere. Do you know PHP? You can try to shut down the Taxonomies part and see if that helps just to prove it’s indeed the issue here.

Anyway, you cat try to comment out in ./mods/custompost_module.php:
– line 17: self::customTax();
– line 54: $tax_list = ...

Is there a way to selectively remove taxonomies while retaining others? I use the widget group taxonomies for assigning widgets to the custom post types.

However, I don’t use big taxonomies when assigning widgets.

I did try that but it throws a 500 server error.

Stupid me, yes, of course… it can’t find $tax_list anymore.
See if this helps… Put this under line 54:
$tax_list = array();

There is no way of selectively removing taxonomies. The problem here is the building of hierarchical tree which takes too long. I think removing the hierarchy would be the only solution *OR* I can try to implement the same structure I did for pages which uses the WordPress Walker class.

This taxonomy term list hasn’t changed appreciably for a couple of months and the plugin did work fine.

Is there a previous version that you would recommend that I try?

It doesn’t have to be the tree itself. It can be something else that takes up a bit more memory or something. Just too less to get the tree processed.

I’m sorry, support for taxonomies has been added a long time ago. I’m afraid that a (very) old version of DW won’t work at all anymore.

I’ve just tested each version through 1.5.0 – with most plugins deactivated and the issue is the same.

Can I hire you to customize this for me so that it will work?

Let me first have a look if I can implement the Walker class here as well as I did for pages. That will probably solve the issue already.

I didn’t realize how critical this plugin was to my site until I couldn’t change settings on a widget. Suddenly I realize how much I depend on the ability to selectively assign widgets.

With something like 1500 posts, pages custom post types, several templates, 18 sidebars and 150 widgets this kind of control has become mission critical. I am happy to financially support something that I am so dependent on.

Thank you very much for your offer. It’s clear to me you really appreciate the effort I’ve taken into DW by making a donation to it.

Until now no luck in finding a solution for you. WordPress does not support the overriding of the Walker class in this matter. Is a flat list (without hierarchy) something you could live with?

Probably, especially if the terms are arranged in their hierarchy. The problem with using term id is that you can’t tell which term is a child of another.

How about a customization that excludes the big taxonomies. For example – unset a couple of the taxonomies from the array before passing it to the function that sorts the hierarchy?

After you get the $taxlist can’t we just unset the unnecessary taxonomies?

I’m not sure. What I want to try is to have a limit in the number of terms in the taxonomy. When it passes the limit, the flat list will be used in stead of going through building a tree.

There is another way tho for terms within the Custom Post Types. When you select the “Individual” option, you can select the widget in the term admin. Unfortunately it doesn’t apply to the term archive.