bravenewniche

I installed ultimatemember-pre-v1.3.69.14 and everything’s working now!

I’ve been able to change first name, last name, email, and password, and the profile remains visible on the front end.

Thanks so much!

I’ve pinpointed the problem.

Changing a user’s email address is making the user disappear from the front-end directory.

I just signed up, using an email that’s never been used in the system. The member profile appeared on the front end. Then I updated the account information, changing the email to another one that’s never been used in the system. The profile disappeared.

I’ll try updating to 1.3.69 and see if this is corrected.

UPDATE (still using 1.3.68):

It’s changing anything in the user account that’s causing the issue.

I went back and tried changing the first and then the last name of a user, without changing the email, and the profile disappeared in both cases.

I then tried changing any Profile field (address, phone, etc.) and all of them could be changed without any issues.

• This reply was modified 8 years, 2 months ago by bravenewniche.

Just did an update of an older site and had this same problem.

This article makes it very easy to switch SSI to use Font Awesome. Up and running in about five minutes:

https://robincornett.com/simple-social-icons-fontawesome/

Is that new, Mike? As I say, the file’s been there for several years and never picked up by WC as a template override.

What I like about this plugin is that it has so much control for those who don’t have coding skills.

And since I find clients have trouble even with shortcodes, I install a plugin that allows for the use of widgets inside of Post or Page content, and then they can use the widget form of this plugin.

Same here, but I’m using this temporary workaround:

thumb=”false” thumb_default=””

For some reason the thumb=false is not turning off the default thumbnail location.

UPDATE: actually, when working with the date= attribute I discovered the proper answer:

thumb=”” date=””

In the documentation the defaults are shown as thumb=”true” and date=”true” so the assumption is (I think rightly) that you should put in “false” to turn the item off… but it turns out you need to make the attribute blank.

Been seeing lots of answers around the web, saying that mime types need to be adjusted through the htaccess file.

Thankfully, there’s an easier answer, at least as of WP 4.0 (maybe earlier, not sure).

If you add the class “no-svg” to your body tag, then WordPress will use the png version of the media player controls instead of the svg.

Here are several ways to add a class to the body tag:
https://code.tutsplus.com/tutorials/adding-to-the-body-class-in-wordpress–cms-21077

Bacon saved – thanks!!

To get around this problem in the short term, I did a CSV import of the taxes we needed, and that did indeed show the rates.

I then tried to delete the three taxes we had manually entered, when I noticed that there is no checkbox or some other way of selecting rows, so the Remove Selected Row(s) function is not working for me.

Is that going to be a part of this fix or is it some other issue or is it unique to my install?

Just discovered that sometime in the last month or so a client’s site has suffered this error message for a series of 50 small ads in the footer.

When I checked the Ad Management listings, all the ads had Show Until dates of June 2014 or later.

However, when I started going into each of them, they had Schedule End dates of 2013…

One of the 50 ads is displaying, and it has a Schedule End date of June 28,2014 although in the Ad Management listings, it says June 28, 2015

So I tried updating the Schedule End date of one of the ads, but it would not save the new year – still says 2013…

This is all still happening after updating to WP 3.9 and AR 3.9.9

In the wpm.php file in the root of the WLM plugin folder, look around line 3168 and you’ll get the handles for the scripts being used in the latest WLM (earlier scripts are just before that point).

You need the handles in order to dequeue the scripts.

Ok, haven’t got much time right now, so this is a temporary fix that removes all WLM scripts from admin post-new.php screens:

function wlm_remove_scripts() {
    global $pagenow;
	if ( $pagenow == 'post-new.php' ) {
        wp_dequeue_script( 'select2' );
        wp_dequeue_script( 'wishlist_member_admin_more_js' );
        wp_dequeue_script( 'wishlist_member_admin_main_js' );
    }
}
add_action( 'wp_print_scripts', 'wlm_remove_scripts', 100 );

I need to target this more to only affect Download Monitor screens, both Add New and Edit screens, but other deadlines are calling me!

I updated to WLM Version 2.80.2027 a few weeks ago, but hadn’t worked with the Download Monitor screens until now – and yes, after going through all my plugins, found that it was WLM breaking the Add File button.

Off to find an answer.

Or maybe something other than WLM! It’s enough of a nuisance to develop with anyway…

DLM uses a custom taxonomy, while your array references the default “category” for posts.

So instead of ‘category’ => 2

Try ‘dlm_download_category’ => ‘name-of-category’

Had a client’s WordTube start showing a blank black box where playlists existed before – after an upgrade to 3.6 and installing Jetpack (I didn’t do the upgrades etc., so I don’t know the exact order of what happened).

Anyway, I just tried the fix here and I’m now seeing the playlists and files are playing fine.

The problem definitely has something to do with serialized data.

I just did a new search and replace on the database to change URLs after the client pointed the domain name at the new server. Once again, all the mail data disappeared from the WordPress admin screen.

There is a one character difference between the temporary URL and the final URL, and I could see in the database that the quantity for the “body” field was exactly one character off.

I had tried running the serialize fixer script the first time this problem happened, with no success. I didn’t try it this time, but instead I manually changed the quantity for the body field – still no luck.

It’s only after I re-enter the data that everything works again. What I don’t understand is that the quantity for the “body” field matches the quantity I’d manually reset – so why didn’t my manual change work? What am I missing in that process?

I compared the full meta_values (my manual change vs after updating all data through the WP admin interface) and everything was the same, except for the quantity of the “body” field…