The HTTP request sent by wp_remote_get() is different from the one that a browser sends. E.g the user-agent is different (see documentation). Some websites respond differently based on this. The second argument of wp_remote_get() allows one to alter the request. Websites might also respond differently depending on the IP or the number of requests received … Read more
Is there any limitation/issue setting/thowing 403 the usual PHP way? header(‘HTTP/1.0 403 Forbidden’); die(‘You are not allowed to access this file.’);
Well this is somehow a very specific topic that is bound to a WordPress development issue. I strongly suggest you to keep track of the trac ticket if you liked my article. That is the best thing you can do I assume for finding out when the problems come into play as well how to … Read more
I just figured out my own issue which I am hoping might help others if they get stuck in this situation. Essentially the problem seemed to be that modsecurity caused the 500 Internal Server error because for some reason (which I have yet to understand) the menu page was sending a bunch of data in … Read more
I also had this issue with wordpress and couldn’t properly resolve it. Ended up with this filthy hack to prevent the error from showing: // Get the current error reporting level $e_level = error_reporting(); // Turn off error reporting error_reporting(0); ob_start(); echo ‘This is a horrible hack’; $buffer_contents = ob_get_clean(); ob_end_flush(); // Reset error reporting … Read more
I was able to track this down to the culprit function add_theme_page(). There There was an additional parameter, per the codex for add_theme_page() that needed to be removed. Removing that seemed to help. function fivehundred_register_admin_menu() { add_theme_page( ‘500 Settings’, ‘500 Settings’, ‘manage_options’, ‘theme-settings’, ‘fivehundred_admin_menu’, plugins_url( ‘/ignitiondeck/images/ignitiondeck-menu.png’ ) ); } add_action( ‘admin_menu’, ‘fivehundred_register_admin_menu’ ); Fixed code … Read more
Because widget_name::__construct() calls WP_Widget::WP_Widget(), which in turn calls widget_name::__construct() etc. A simple solution would be to make widget_name::__construct() call WP_Widget::__construct() directly. Also see http://core.trac.wordpress.org/ticket/16768#comment:9
I wouldn’t use that hook. Here’s why Try something like this using admin_notices. function wpsites_admin_notice() { $screen = get_current_screen(); if( ‘post’ == $screen->post_type && ‘edit’ == $screen->base ){ ?> <div class=”error”> <p><?php _e( ‘Updated Demo Message!’, ‘wpsites’ ); ?></p> </div> <?php }} add_action( ‘admin_notices’, ‘wpsites_admin_notice’ ); Untested.
The issue if that your conditional is trying to convert an Object into things that it cannot be converted to. WP_Query returns a WP_Query Object so when it’s tested against Object == 0 – it tries to convert the object into a number during the comparison but cannot. You instead need to test against $results->have_posts() … Read more
This usually happens when you are trying to do admin navigation stuff and you aren’t hooked into admin_menu. If you hook in before that, $menu hasn’t been created yet. add_action(‘admin_menu’, ‘my_plugin_add_menu’); function my_plugin_add_menu(){ $ptype=”my_post_type”; $ptype_obj = get_post_type_object( $ptype ); add_submenu_page( ‘my-menu-item’, $ptype_obj->labels->name, $ptype_obj->labels->all_items, $ptype_obj->cap->edit_posts, “edit.php?post_type=$ptype” ); }