Title: Close Button and return on Post Last modified: August 20, 2016 --- # Close Button and return on Post * [professor99](https://wordpress.org/support/users/professor99/) * (@professor99) * [13 years, 6 months ago](https://wordpress.org/support/topic/close-button-and-return-on-post/) * One thing that’s a pain with WP User Frontend is that there’s no Close button which means your always hitting the back button on the browser to return to the original referral page. This may be three pages depending on circumstances. * Also once you posted you go to the new page which also means hitting the back button multiple times to return to the original screen. This problem was discussed here. [http://wordpress.org/support/topic/plugin-wp-user-frontend-redirecting-after-posting?replies=15](http://wordpress.org/support/topic/plugin-wp-user-frontend-redirecting-after-posting?replies=15) * Either way the intuitive expectation is that after the post or if the Close button is pressed the browser should return to the original referring page (updated in the case of a new or edited post). * Ideally a pop up window or overlay using ajax would be the best for new pages as the author wouldn’t have to leave the original page. However in the case of editing content this wouldn’t work directly as the author would expect the original text to be updated. This is possible via ajax techniques but is complex and best left to later. Incidently some editors use inline techniques to do this on the original page eg [Raptor](http://wordpress.org/extend/plugins/wp-raptor), [Front End Editor](http://scribu.net/wordpress/front-end-editor). * In any case for now I’m just going to concentrate on the minimal changes needed to implement a Close button and return to original page on Post. * The following code and considerations refer to the New Post code only in wpuf- add-post.php and the changes will also have to be added to the Edit Post code. * To get the original page the use of the php variable $_SERVER[‘HTTP_REFERER’] does the trick. However this only works for the original page. The two exceptions where this doesn’t work follows. * 1. When the Submit button is pressed Frontend posts to itself. 2. If the user isnt logged in and uses the frontend login prompt to login. * The Submit problem is easily solved by providing a hidden Input field with the original referral page as follows. * ``` $wpuf_referer = $_SERVER['HTTP_REFERER']; ``` * For the login problem two approaches can be considered. * 1. Add the referral page as a query variable to the login url and have the script deal with it. * Original Code. * ``` function shortcode( $atts ) { .... if ( is_user_logged_in() ) { $this->post_form( $post_type ); } else { printf( __( "This page is restricted. Please %s to view this page.", 'wpuf' ), wp_loginout( get_permalink(), false ) ); } .... } ``` * Updated code * ``` $wpuf_referer=''; function shortcode( $atts ) { global $wpuf_referer; .... if ( isset( $_POST['wpuf_post_new_submit'] ) ) { $wpuf_referer = $_POST['wpuf_referer']; } else if (isset( $_GET['wpuf_referer'] ) ) { $wpuf_referer = $_GET['wpuf_referer']; } else { $wpuf_referer = $_SERVER['HTTP_REFERER']; } if ( is_user_logged_in() ) { $this->post_form( $post_type ); } else { printf( __( "This page is restricted. Please %s to view this page.", 'wpuf' ), wp_loginout( get_permalink() . '?wp_referer=' . $wpuf_referer , false ) ); } .... } ``` * 2. Delete the login option as really this is an error as an edit/new page link shouldn’t be offered to a non-logged in user anyway. Instead check for this as part of the post_form function. * e.g. * Original Code for function shortcode( $atts ) * ``` function shortcode( $atts ) { extract( shortcode_atts( array('post_type' => 'post'), $atts ) ); ob_start(); if ( is_user_logged_in() ) { $this->post_form( $post_type ); } else { printf( __( "This page is restricted. Please %s to view this page.", 'wpuf' ), wp_loginout( get_permalink(), false ) ); } $content = ob_get_contents(); ob_end_clean(); return $content; } ``` * Updated Code for function shortcode( $atts ) * ``` function shortcode( $atts ) { extract( shortcode_atts( array('post_type' => 'post'), $atts ) ); ob_start(); $this->post_form( $post_type ); $content = ob_get_contents(); ob_end_clean(); return $content; } ``` * Original code for function post_form( $post_type ) { * ``` function post_form( $post_type ) .... $info = __( "Post It!", 'wpuf' ); $can_post = 'yes'; $info = apply_filters( 'wpuf_addpost_notice', $info ); $can_post = apply_filters( 'wpuf_can_post', $can_post ); ..... } ``` * Updated code for function post_form( $post_type ). Includes edit_posts security fix. Also puts the info filter after the can_post filter to allow the can_post filter to change the info message. * ``` function post_form( $post_type ) { .... if (!is_user_logged_in() ) { $can_post = 'no'; $info = __( "User is not logged in.", 'wpuf' ); } else if (!current_user_can( 'edit_posts' )) { $can_post = 'no'; $info = __( "User doesn't have post capability.", 'wpuf' ); } else { $can_post = 'yes'; $info = __( "Can't post.", 'wpuf' ); //default message } $can_post = apply_filters( 'wpuf_can_post', $can_post ); $info = apply_filters( 'wpuf_addpost_notice', $info ); ..... } ``` * I’m a purist so I’ve implemented the second approach as it makes Frontend more programmer friendly. * Given the above all thats left to do is the Close button and the Post Submit redirect. * For the close button simply add the following code at the end of the post_form function * ``` if ($wpuf_referer) { //Swap the following lines if you don't want to be bothered updating admin/settings-options.php and wpuf-options-value.php //echo '
Close
'; echo '
' . esc_attr( wpuf_get_option( 'close_label' ) ) . '
'; } ``` * The Post Submit redirect requires the following update * ``` function submit_post() { global $userdata; global $wpuf_referer; ... if ( $post_id ) { //$redirect = apply_filters( 'wpuf_after_post_redirect', get_permalink( $post_id ), $post_id ); $redirect = apply_filters( 'wpuf_after_post_redirect', $wpuf_referer, $post_id ); if ($redirect) { wp_redirect( $redirect ); exit; } } ... } ``` * I will post a link to my complete code later which includes the changes outlined in my other recent posts. * Cheers TheProfessor * [http://wordpress.org/extend/plugins/wp-user-frontend/](http://wordpress.org/extend/plugins/wp-user-frontend/) Viewing 3 replies - 1 through 3 (of 3 total) * Thread Starter [professor99](https://wordpress.org/support/users/professor99/) * (@professor99) * [13 years, 6 months ago](https://wordpress.org/support/topic/close-button-and-return-on-post/#post-3163706) * One thing I forgot to mention is that this change only addresses the use of a separate Add Post page using the wpuf_addpost shortcode. * Some consideration also needs to be given to using this as an in page editor like the “Reply” form at the bottom of this page. In this case the Close button isn’t appropriate but you would always want to be redirected back to the original page after login or post. * More thoughts on this later. * Cheers TheProfessor * Thread Starter [professor99](https://wordpress.org/support/users/professor99/) * (@professor99) * [13 years, 6 months ago](https://wordpress.org/support/topic/close-button-and-return-on-post/#post-3163709) * Quick update * The only way I can think of to allow for easy optional use of the “Close” button is to allow for it in the wpuf_addpost shortcode as follows. * [wpuf_addpost shortcode close=”true”] [wpuf_addpost shortcode close=”false”][ wpuf_addpost shortcode] //default close=”false” * I will code it so the default (close=”false”) conforms to the default WP User Frontend installation except that it will redirect to the current page for submitted posts as I think that is preferable to the present where it redirects to the new post (and I cant see it causing any problems with updates of old installs). * Cheers theProfessor * Thread Starter [professor99](https://wordpress.org/support/users/professor99/) * (@professor99) * [13 years, 6 months ago](https://wordpress.org/support/topic/close-button-and-return-on-post/#post-3163736) * Have relented and decided to keep the login form option so it remains backward capable with the current Frontend installation. * I’ve done it in a way that allows programmers to use ‘wpuf_can_post’ filter to allow unlogged in users to post if they wish which isn’t possible in the current version and has been asked for by a few users. Unlogged users posts in this case will be mapped to the user given by the admin option “Map posts to poster”. Whilst an admin option could be provided to make this possible without using the filter it isn’t a good idea as spambots could exploit this. So if you do use this filter for this in my updated version make sure you include something like a captcha to stop this kind of exploit. * Will post soon the link to the code for this Viewing 3 replies - 1 through 3 (of 3 total) The topic ‘Close Button and return on Post’ is closed to new replies. * ![](https://ps.w.org/wp-user-frontend/assets/icon-256x256.gif?rev=2818776) * [User Frontend: AI Powered Frontend Posting, User Directory, Profile, Membership & User Registration](https://wordpress.org/plugins/wp-user-frontend/) * [Frequently Asked Questions](https://wordpress.org/plugins/wp-user-frontend/#faq) * [Support Threads](https://wordpress.org/support/plugin/wp-user-frontend/) * [Active Topics](https://wordpress.org/support/plugin/wp-user-frontend/active/) * [Unresolved Topics](https://wordpress.org/support/plugin/wp-user-frontend/unresolved/) * [Reviews](https://wordpress.org/support/plugin/wp-user-frontend/reviews/) ## Tags * [close](https://wordpress.org/support/topic-tag/close/) * [redirect](https://wordpress.org/support/topic-tag/redirect/) * 3 replies * 1 participant * Last reply from: [professor99](https://wordpress.org/support/users/professor99/) * Last activity: [13 years, 6 months ago](https://wordpress.org/support/topic/close-button-and-return-on-post/#post-3163736) * Status: not resolved