mokana

Yes, this issue stills persist so I turned off Directory . . .

Why are you closing it out when there has been nothing provided to solve this functionality issue?

Thanks

Which Plugins are these?

There are no plugins that conflict with UM.

As stated, the images show up fine in the profile; both cover and profile images.

I have not installed the PHP files that supports mobile image uploads.

Please provide more detail on these image optimization plugins. As stated, I do not have any related plugins installed.I do not run third party plugs other than system backup, IP prevention, and maintenance under construction.

Please also respond to the other post regarding the two fields added to the Privacy Tab under the Account Page. This has messed up the flow of the site big time.I have turned off Directories because I had to turn off the Privacy Tab and the fields that allow a user to hide their profile are now hidden because no provision was made to hide the added fields. These fields should have been added under a new tab with visibility capabilities provided under setup.

Also please respond to when the Field Display patch provided that solves the issue with fields displaying correctly on the Profile Page will be part of a public release. I have downloaded the patch but am afraid to do anything with it based on prior history.

Thanks

I am so getting exhausted. I am to the point where if I see an UM update, I freaking panic . . . .

@ultimatemembersupport do you have a time frame when this will be made available in a general release. I freak anytime I have to do an upgrade via the back door as experience has proven that it breaks stuff.

@ultimatemembersupport hello!

Nah! This is messed up! I was thinking maybe I broke something! But nope! Version 2 did. There are fields that I need displayed during edit that cannot be edited as their status drives the display of other fields. They have to be displayed for informational purposes. my functionality is broken and I am at a standstill until this is fixed.

No matter what the Visibility is set to, fields that are not marked as editable will not show in the Edit session of the Profile.

I am doing more testing.

When I set Visibility to Everywhere, I am able to see the fields on the Profile when not in Edit Mode. I have the Can user edit this field? set to no. However, this setting does not display the field in Edit Mode. Only when I set the Can user edit this field? YES does the field display in Edit Mode.

The way I had it working before I upgraded to Version 2 was that the fields would display only in Edit Mode and the fields themselves were not editable, just displayable.

I guess if only the Owner of the Profile can see the information on the non Edit screen will work, but it was working the way I wanted it to before. I ran it this way for months.

How do I get screen shot images to you?

As stated before, the fields only become visible if I select that the Edit Field is editable by the Profile Owner. I need the Profile owner to see the fields but not edit them. This worked fine before I upgraded to Version 2.

Privacy: Set to Profile Owner and Admins

Visibility: Tried both Everywhere and Edit Only

Field Required: Tried setting this. It does not have any affect on visibility, but does prevent the form from being saved and there is no error given why the form did not save.

View by profile owner and administrator.

It makes no sense to build a page in which is never seen. I do not understand this logic. Why assign a page to a link that does nothing more than force an instant logoff?

The intent here is that a user is taken to the page, where the user then confirms they want to logoff. Like does Facebook and every other widely used platform.

I have a link set up that takes the user to a page, there they confirm, then they are logged off. I do not link this page to UM. I then call the log off routines myself and clear sessions cookies and such.

I built a dummy Logoff page and linked it to UM in the Profile Menu where a user can also logoff. My thoughts are that few people will go to their profile page and will mostly use the visible link I provide at the top of every page. This is a workaround I came up with. If UM ever hooks it in the way I think they should, my Page will be called without modification. Right now UM does not even call the log off page. It never gets to the page. Is never resolved within WordPress core. If UM fixes this, it will call the dummy page which I have already handled with a redirect.

Hello again!

At what point is the subtitle guaranteed to have been saved? I ask because of this:

function post_notification ( $new_status, $old_status, $post ) {

if ( $old_status == $new_status )
return;

if ( ($new_status == ‘publish’) && ( ($post->post_type == ‘podcast’) || ($post->post_type == ‘post’) ) ) {

include ‘post_notification.php’;

} else {

return;

}

}
add_action( ‘transition_post_status’, ‘post_notification’, 10, 3 );

I am doing an off site notification after the POST is Published, which means it is in the Database.

In the post notification function I have the $post object, but the subtitle data simply is not there.

This is my recent test:

$subtitle = get_the_subtitle( $post->ID,””,””,false );

$json = json_encode(array (
‘title’ => $post->post_title,
‘subtitle’ => $subtitle,
‘permalink’ => get_permalink( $post->ID ),
‘imageURL’ => $postImageURL,
‘type’ => $post->post_type,
‘category’ => $arrayOfCategoryName,
‘excerpt’ => $post->post_excerpt,
));

echo $post->post_title;
echo “<br>”;
echo $subtitle;
echo “<br>”;
echo the_subtitle();
echo “<br>”;
echo get_permalink( $post->ID );
echo “<br>”;
echo $postImageURL;
echo “<br>”;
echo $post->post_type;
echo “<br>”;
echo $arrayOfCategoryName;
echo “<br>”;
echo $post->post_excerpt;
echo “<br>”;

And everything prints out as expected but the subtitle.

Thanks

MOKANA

This is the exact code fragment I am using. All other data element fetches using $post->ID come through with no issue.

$subtitle = get_the_subtitle( $post->ID,””,””,false );

$json = json_encode(array (
‘title’ => $post->post_title,
‘subtitle’ => $subtitle,
‘permalink’ => get_permalink( $post->ID ),
‘imageURL’ => $postImageURL,
‘type’ => $post->post_type,
‘category’ => $arrayOfCategoryName,
‘excerpt’ => $post->post_excerpt,
));

also . . . clear the cache under settings . . . for a related issue I found the solution is to disable caching under Settings . . . poof . . . no more of these mismatch issues between the core data and array cached in wp_options table . . . all metadata is stored in wp_usermeta and the wp_options cached data is a flash of that . . . disabling UM caching blows this layer out . . .