redfez

The link to the Github thread is very informative I recommend heading there first if you are finding this thread after googling the issue. To resolve mine I followed @kaycp instructions – deleted my old (5 years old) API key and secret by rolling it. This gave me a new Public Key and a I created a new Secret Key which I put into WooCommerce. I also got the message in Stripe about the missing information and after heading back to the main dashboard saw a notice that I needed to confirm the identity of the business officer which I did. They seem to be working nicely together now.

Nothing wrong with your code far as I can tell, its just not finding the $key value of ‘title’ so its returning NULL – which in this case is nothing.

Check your spelling or name of the meta value in your database (PHPMyAdmin) and make sure it is in the user meta table.

Or run a query to return all meta for that user and look at the list of meta_key entires to see if it is showing up at all.

https://developer.www.ads-software.com/reference/functions/get_user_meta/

See the example by Codex to return all meta_value thats stored.

That should point out where to look further.

@o0s0o Try installing the default BuddyPress install with no other plugins active and if you are still not seeing the Repost icon show up please go to :

Settings > BuddyPress > Options

Under ‘Main Settings’ check if the Template Pack option is set to BuddyPress Nouveau. If it is, change it to BuddyPress Legacy and see if the icon shows up on your activity stream.

On our end W3TC was caching the scripts and once I cleared the cache of those specific objects (CDN Purge) it worked fine. Thanks guys ??

Same issue here I am using latest wordpress 4.9.6 with the following plugins:

Ninja Forms
Version 3.3.4

Ninja Forms – Conditional Logic
Version 3.0.10

Ninja Forms – File Uploads
Version 3.0.5

Ninja Forms – Layout & Styles
Version 3.0.12

Ninja Forms – Multi-Part Forms
Version 3.0.9

Any clue on what is causing this, previous versions were working fine with my setup and all plugins activated.

The issue is created by the type of SSL used. Our SSL is an EV Multidomain which does not support domain wildcards.

The script calls full URLs which include the www as part of the formed URL called by the script – which breaks the security of the SSL and results in that resource being blocked.

If you have a wildcard SSL this will not affect you. Or if you have a multi-domain SSL which includes the www of your domain it will also not affect you. In my case it does affect us as our multidomain SSL does NOT include the www.

Hope this helps someone.

Thanks stianlik I’ll take a closer look at how the file manager plugin I want to use is structured. I think it should be possible as long as I can identify when the save attachment call is made, and see if there is a way to hook to that. Thanks again, I’ll post back when I have a clearer picture.

Another vote for this – as a social network interaction this would be awesome for comments and status updates on the activity timeline, Groups etc.

Same, I love the basic idea of the plugin but it doesn’t do much except but the button there, I can’t seem to find how/where those likes are stored against the item and if/how the item author is notified?

Had this same issue as well, the host said it referenced akamai.net which is what got it flagged as malicious. I asked them to whitelist it and it is working now, just wanted to post my feedback on it.

Gets stranger and stranger. I increased WP_MEMORY_LIMIT up quite high, much higher then is being used to execute the querys – 385Mb. Still returns 404 but only when I run specific combination of filters.

Also, turned on WP_DEBUG and only one line appears:

Notice: Constant AMR_USERS_STORE_URL already defined in /home/pesacoma/public_html/wp-content/plugins/amr-users/admin/updates-page.php on line 5

I am beginning to suspect it may actually be a corrupt user record in the database or something. Is there a way to find out if there is a corrupted user record? Or are there chatacters that could stored inside a user record that could cause the result Im getting?

This is the url that is generated that is returning the 404:

https://www.userdomain.com.au/wp-admin/users.php?page=ameta-list.php%3Fulist%3D1&csv=1&_wpnonce=b6fc1d93b4

This is the URL that is in the browser when the query runs and works:

https://www.userdomain.com.au/wp-admin/users.php?page=ameta-list.php%3Fulist%3D1

Some exports are working fine but it seems like anytime the user list has more than about 1100 entries I get a 404 page. Is there any way to see if it is hitting max memory or other resource limit?

I solved this one with investigation. For those interested, when importing tables from the single site into the database I had to rename the tables with a numbered prefix to meet the requirements of multisite. Thus:

wp_options

became:

wp_3_options

Inside this table there is an option_name wp_user_roles where the data is stored, this option_name needed to be changed to wp_3_user_roles to make it work for my install. Once changed all roles became available again.

Thanks Anmari, I will go through your suggestions and post back here with what I find.