I have a custom plugin 'Charts' that has it's own menu. In that menu are links to the 3 pages for the plugin - 'Charts', 'Add Chart' and 'Edit Chart'. However, I don't want to display the link to 'Edit Chart'.

Here is how I add the page in question -

$this-&gt;pagehook = add_submenu_page('charts', __('Edit Chart'), __('Edit Chart'), 'edit_charts', 'edit-chart', array(&amp;$this, 'on_show_page'));


I've scoured the internet, and cannot find a way to do this (that works). It's possible to remove whole top level menus (not what I need), and you can remove individual entries from the $submenu global (but doing that also removes the registered capability), so no one can access the page -

global $submenu;
if(!empty($submenu['charts'])) : foreach($submenu['charts'] as $key =&gt; $page) :
        if($page[0] === 'Edit Chart') :

            /** Removes all permissions to access the page */
            //unset($submenu['charts'][$key]);              
            /** Removes the title, but the menu entry still exists, so it looks odd */
            $submenu['charts'][$key][0] = '';

        endif;
    endforeach;
endif;


I've looked in to hiding it via CSS, but can't see a way to do that through the HTML that Wordpress generates -

&lt;li&gt;&lt;a href="admin.php?page=edit-chart" tabindex="1"&gt;Edit Chart&lt;/a&gt;&lt;/li&gt;


I've also considered jQuery, but that has similar limitations to the CSS route, plus I refust to believe that I am the only one that has ever wished to do this - there must be a way, I just can't find it!

Any hints and tips appriciated.

Thanks.


Question: How do I create a simple yet complex business layer?
Answer: Component architecture can provide good tools for fighting complexity of the business layer. For example, notifications can be done with registering subscribers (event handlers). A lot of logic can be done by adaptors, which will provide certain specific interfaces to your User and Customer interfaces. This way logic can be decoupled, making large monolithic classes unnecessary. Hopefully your platform already has some proven component architecture you can use, which is much better than implementing "plugins" from scratch.

Older answer (see first comment):


  My first impression of having CustomerRegistration and
  UserRegistration classes with the methods mentioned is that OO
  analysis has not been properly accomplished. I always thought that
  having sensible entities at business layer is the only way to prevent
  the mess. My advice would be to redesign (if it is not late yet) the
  business layer classes to better reflect business entities and not
  frontend processes. It may well be, that after such a redesign
  complexity will be a fraction of what you have now, and, more
  important, natural representation of the problem domain will answer
  your goals better than classes, combined with seemingly related
  functions.
  
  For example, even as such, UserRegistration should not have DeleteUser
  method! The task naturally belong to UsersManager class or maybe
  UserRegistry, if you wish.
  
  In short, I think the problem is that classes are formed around
  action-like entities, which requires much more interconnections
  (=mess) than class system around (say) User, Customer, and Managers of
  those two (managers are more like containers).
  
  There is little point of making User Management OOA from scratch. Good
  examples can be found from many frameworks, and sometimes they handle
  much more complex things, like fine-grained authorization,
  role/permission management, group management, etc.