Possible to make user Capability to Edit Pages, but not to create new pages?

!important didn’t work either. I wasn’t aware I could use unset for this.
unset( .button.add-new-h2 ); didn’t work

(Honestly, I just removed the actual button code in the core file. But I like doing things the long, tricky way. Also, I don’t want to do it every time I update WordPress.)

unset( .button.add-new-h2 );

You can’t unset CSS classes, unset is for PHP … it won’t work on CSS ..

What i was saying was, why can you not unset this menu item using the same method we used further up the topic.

Also, I don’t want to do it every time I update WordPress.

See my example here again.
https://www.ads-software.com/support/topic/370002?replies=17#post-1419254

It wouldn’t require that you touch any core files (it’s a function, which could be placed in a plugin or theme functions file), so there’s no problem with upgrading..

Ok, I see what you’re saying. I don’t think this is a menu item. It’s the “Add New” button above “All | Published | Trash” on edit-pages.php. It doesn’t appear to be a function, just a standard html link with a button image.

well, lol, unless I can unset this function <?php echo esc_html_x('Add New', 'page'); ?>

Where are you reading that code from?

edit-pages.php, line 144
<a href="page-new.php" class="button add-new-h2"><?php echo esc_html_x('Add New', 'page'); ?></a>

Why are you editting core files though?
Are you wanting to hide this stuff from admins to? (ie. remove it for any users, admin or not)

If you’re hiding this for particular users, you could look at doing it with some form of role management, you don’t need to be making changes to core files, that you would essentially lose after any upgrade(unless you keep track of all changes and re-apply them after each upgrade), you should instead remove the necessary capabilities from the given role.

If you take away the ability for a set role to do a given task, such as adding/editing pages, those items will automatically be hidden from any user with that role, menu items etc… (easy example would be to login to your site as a subscriber, you’ll immediately notice various areas missing).

Right now you’re not removing any capability, you’re simply hiding the links, meaning that any savy user that realises would still be able to add/edit pages with the right URL query string in the admin area(if the role has the capability required).

If you want to clarify on why it is you’re hiding these perhaps i can offer further advice, but right now i’m a little worried you’re hiding these links in expectation that users won’t be able to do certain tasks when the links are removed, which wouldn’t really be the case(if their role has that capability).

NOTE: edit-pages.php won’t be used as of WP 3.0, just a pre-3.0 warning since you’re making changes to it.

I have the capabilities set correctly. The button/link I’m removing actually does not work for the subscriber role, yet is still visible. If they click it, it doesn’t work, says access denied/no permission/etc. Since they can’t use it, I don’t even want them to see it or be curious about it.

For my purposes, it doesn’t matter if it’s not visible to the admin b/c:
1. The side submenu link is still available for the admin.
2. I can also type in the url manually to reach the page.

In WP 3.0, I may have to edit those core files too. If that’s not feasible, well I’ll just have to let this final customization slide then. Any ETA on WP 3.0? weeks? months?

You could do it with jQuery, or the CSS should work .. it depends if you have your CSS read before or after the admin CSS is loaded by WordPress.

Just seems a little drastic to be going in there removing a link when CSS should be fine(being a non-JS solution)..

Are you doing this inside a plugin or theme functions file? (anything you’re not changing in core files)..

I can help you make a basic function for adding CSS to the admin if you like.. we should be able to target the edit-pages.php page specifically to(so the additional CSS isn’t loaded on every admin page).

RE: 3.0, personally i don’t know if there’s a particular set date, the difference mentioned before was just an observation, and i imagine the change is related to the custom post type support we should hopefully see in 3.0.

I’m placing the CSS code into /wp-admin/wp-admin.css. I don’t know if that is the right file, or if it loads before or after the page loads. I asked about WP 3.0 because if it’s coming soon then I’d wait for it instead of trying all this on WP 2.9.

If you had a function that targets edit-pages.php that would be great! I’m not familiar with writing plugins, but if that would make it upgrade-proof then that’d be best.

Yes, pretty much any page in the admin can be targeted…

Let me go test some code(under 2.9) and i’ll report back, so i don’t post something that doesn’t work..

This works..

add_action('admin_init','my_init_method');
function my_init_method() {
	// Hook onto print styles action for edit-pages page only
	add_action('admin_print_styles-edit-pages.php','add_edit_pages_css');
}
function add_edit_pages_css() {
	?>
	<style type="text/css">
	.button.add-new-h2 {display:none!important}
	</style>
	<?php
}

There’s another method to do the same, to ensure it loads your CSS after the WordPress stylesheets, using wp_enqueue_style, but that would mean loading an external CSS file just for a single line of code (not really worth it is – i did do it that way before changing my mind and posting the above instead).

Both approaches work the same, but the above is smaller and easier to understand, and won’t require any external files, just move that code into a plugin or a theme’s functions.php(how i tested it).

Sweet! Your code works great. Thanks a lot t31os_!!!

One last thing… Any way to set the height of the text box when editing a page? The box where you can drag the bottom-right corner. I want to expand it to about twice the size and have that as the default.

Yeah i use to do that myself..

This works without the init .. (not sure the last one needed it either) ..

add_action('admin_print_styles-page.php','increase_textarea_css');
add_action('admin_print_styles-page-new.php','increase_textarea_css');
add_action('admin_print_styles-post.php','increase_textarea_css');
add_action('admin_print_styles-post-new.php','increase_textarea_css');

function increase_textarea_css() {
	?>
	<style type="text/css">
	textarea#content {height:600px!important}
	</style>
	<?php
}

There’s 4 cases to catch, but we can just reference the same function since we’re using the same CSS for each case. 600px is just an example(you’ll notice the difference), adjust as required..

I’m off to bed shortly(4am here), so hope that helps, i’ll check by tomorrow to see how you got on.. ??

Great, thanks again t31os_!