sayze35

I saw the reason(s) WHY the form is not working:

look at the source code on the inputs for name and email, you will see “disabled” is added to the input elements ??

please fix ASAP

close

Well, I guess it was a cache issue? It’s working now.

update:

This code doesn’t create the error:

add_filter( 'woocommerce_new_customer_data', function( $data ) {
    $data['user_login'] = $data['user_email'];
    return $data;
} );

BUT now, new issue:

the recipient of the gift gets 2 emails:
One is saying, you were bought a gift.
Second is providing username and link to sign.

THE 2nd one is NOT being sent. Anyone know why?

Still, why does gifting not work when you make WC username be the email?

thanks for any help on this!

PS. we are not charging any upfront payment. only want to discount future payments. BUT use a coupon to get such discounts.

how to allow that?

Hello… I was incorrect, your code does keep the check box checked ??

but it doesn’t display, the recipient email field? How to do that?

THANKS!

Hi @laceyrod

note: this field is for the WC Gift Subscription checkbox, where the “gifting_999_option” ID is unique to your check…. you need to change the _999_ to your specific field name.

wcsg_recipient_checkbox_checked is for the email of the customer, which is not the same field.

add_filter(‘wcsg_recipient_checkbox_checked’, ‘__return_true’);
is hardcode for the WC…. there isn’t one for WC Gift Subscription?

OR is there?

FYI. my original code does check the box, but something is removing the autocheck, assuming the hook is TOO EARLY? but what hook should I use that is later?

this is working:

function checkFunc()
{
	global $pagenow;
    if ( 'index.php' == $pagenow or 'profile.php' == $pagenow ) {

        if ( ! current_user_can( 'manage_options' ) && ( ! wp_doing_ajax() ) ) {
            error_log(" ##### breakin ##### admin access blocked this user IP:".getUserIpAddr());
            wp_safe_redirect( site_url() ); 
            exit;
        }
    }
    
}
//add_action('plugins_loaded', 'checkFunc');
add_action( 'admin_init', 'checkFunc', 1 );

BUT surely that is NOT the way to do it?

I saw multiple ‘wrong’ ways or ways that don’t work out on the internet.
THERE must be a simple, easy and full-proof way to prevent subscribers from seeing the dashboard? The above way is not full proof.

IF admin, they can see or do whatever.
IF subscriber, they can ONLY be redirected to the /subcriber/page/
AND they need to be able to upload, submit, etc. etc. without being blocked.

I just need to prevent subscribers from “viewing” the wp-admin pages, NOT preventing them from executing/using WP code or functionality. Can that happen? How?

thanks

Question is there a difference between allowing a user (meaning a subscriber) to “execute” wp-admin code/files AND being able to “read” or view the wp-admin/ pages?

So… I tried this:

// PREVENT any non admin person from seeing admin pages
function checkFunc()
{
	// get URL, if user on dash board, do nothing
	$expl = explode("/",$_SERVER["REQUEST_URI"]);
  	if ($expl[1] == "wp-admin") {

		if (is_admin() && !current_user_can('administrator')) {
			wp_safe_redirect(home_url(), 302);
			exit;
		}
	}
}
add_action('plugins_loaded', 'checkFunc');

same problem???
That does not work because the user functionality is doing things that (for some reason) uses or calls “wp-admin” pages and therefore, the same issue happens ??

example:
you save some data and
POST /wp-admin/admin-post.php happens and the above hook fails for the user.

how to get around this?
=> where to add code or hook that does not prevent a user from being a user?
I only want to stop the user IF the user tries something they are NOT supposed to do, etc. go to the wp-admin pages ??

Hi @ketanvyawahare,?
thanks for the help.

So I saw a bad side effect on using admin_init.
I then used your snippet and same issue (although the process went a little further).

The process I’m talking about is users being able to complete some functionality.
The functionality has javascript and ajax (which is why I think the admin_init STOPPED the user).

And on your snippet, no visible error, but the process was not completed.

NOTE: when I removed BOTH of the hooks, the user’s have no problems.

SO…
A) It seems I ONLY need to check (fire the hook) IF a user is trying to access an admin URL?
B) Do nothing if a user is doing user related things?

Your thoughts?

Am I missing something IF I add a line of code to check IF the URL is /wp-admin/
or something like that? Is that good idea?

Or any other ideas or thoughts as to how I allow users to do user things?

THANKS!

https://codex.www.ads-software.com/Plugin_API/Action_Reference/admin_init

1) that means ANY user will have the admin_init hook fired, correct?
2) is that really the way to identify any NON admin?
3) look at that __wp_die() function… what is __ before the name?

thanks

https://codex.www.ads-software.com/Plugin_API/Action_Reference/admin_init

that means ANY user will have the admin_init hook fired, correct?

thanks

THANK YOU bcworkz…
this type of information is GOLD. extremely needed (can’t be found anywhere?)

even worse, if you did find same/similar information… you would never know if it old, can be trusted, or some random person was just talking BS.

thank you!!!

PS. So why doesn’t WP Core provide details/information like you did?

thanks bcworkz,
??

from your other post to mine (thanks for that link!)

I see this:
https://codex.www.ads-software.com/Plugin_API/Action_Reference/wp_login

IMO, that seems the most optimal place to redirect a logged-in user?
am I wrong? However, hardly anyone promotes that?

But
a) it only happens once after a successful login
b) you will “know” the user ID

as A and B above are NOT known in the other ‘related’ hooks about redirecting???

thoughts?

PS. What I don’t understand about WP Core developers and the documentation, this post/reply seems the MOST obvious info that ANY person working with user management in WP would need to know… but it basically does not exist in any simple format?
Am I missing something?

thanks for the help!