docarzt

1.3.58 resolves this issue.

If you need a quick and dirty fix while waiting for the plugin update, put this in your functions.php theme file:

This will update the password. The password change email doesn’t seem to go out, but this might be because I’m on a vagrant.

Ignore this, 1.3.58 fixes the issue…

Definitely. Update resolves the problem, but since it’s a paid extension we customers should be informed immediately, preferably through a dashboard message, that the functionality is limited in some way so we can disable it or pass that along to our customers so we don’t look bad.

I can confirm this problem is a bug in the plugin. In: um-actions-account.php

if ( $_POST['user_password'] && $_POST['confirm_user_password'] ) {
			$changes['user_pass'] = $_POST['user_password'];
			add_filter('send_password_change_email','um_send_password_change_email');

		}

		$arr_fields = array();
		$secure_fields = get_user_meta( um_user('ID'), 'um_account_secure_fields', true );
		if( isset( $secure_fields  ) ){
			foreach ( $secure_fields as $tab_key => $fields ) {
				if( isset( $fields ) ){
					foreach ($fields as $key => $value) {
						$arr_fields[ ] = $key;
					}
				}
			}
		}

		$changes = array();

The function detects a password change on line 12 and inserts that into the list of changes array $changes, however line 30:

$changes = array();

Re-initializes $changes and therefore removes the password update. If I move

$changes = array();

to BEFORE the password change detection, it works fine.

Obviously not a good fix because an update of the plugin would invalidate the edit so don’t edit your core plugin files to get it working. Should be fixed by the author ASAP!

Yup on that one it is a completely virgin install.

It’s weird right? Seems like bad behavior on WordPress’ behalf. I’m going to submit it as a bug.

Sure for instance here the issue is with an unaltered Twenty Fifteen. The WordPress install is fresh as well.

https://intensewp.com/

you’ll be able to see that

https://intensewp.com/page/1000

Shows the front page, and

https://intensewp.com/page/{insert any number}

Will as well.

Also I’m talking on the back end.

It’s a post with 10 of these:

<!-- nextpage -->

There must be a way since wordpress itself can do it.

Hmmm… “they” told me you guys were good. ??

Actually I’m following the Codex’s recommended method for displaying content retrieved with the get_the_content function.

That is actually the built in wordpress filter. ‘the_content’

Strangely if I put:

print $content

It works fine and I see the text I added. So I suspect my problem is that

$content = apply_filters('the_content', $content);

Is ignoring my specification of $content and grabbing the_content from the global query response? Maybe?

I would much rather get the support than have to request a refund. Honestly, I blame Facebook. The developer platform itself is buggy as all get out. But in general when you pay money you expect something to work.

I hate to break it to you, but the actions plugin is a piece of junk with zero documentation and I’ve been trying to get support since I bought it to no avail. I think we are screwed.

I don’t want my page to appear under appearances though. Also I’d still like to have an understanding of how add_menu_page is supposed to work./