Stuart Silvester

You're seeing those because there was an issue fetching the notification content from the server. In that case it falls back to default text and links to the root of the community.

The issue could be an authentication failure or something else. If you try disabling push on the community and re-enabling it, do you see the full notifications?

If you haven't already I would recommend looking at the server access logs (and any other logs) around the time those files were first created.

You might also want to check the `core_javascript` table for the file you're finding in the movies javascript folder. It sounds like it may have been inserted into the database which is then written to the filesystem when caches are cleared (i.e. when an app is installed).

This has been fixed in 4.7.12 Beta 3

Thanks, I just reproduced it. It's specific to replies and not new PMs.

I'm still getting notifications for PMs, are you getting any email notifications for other things?

This isn't valid, we don't have an iOS Startup image here and the app is perfectly installable (inc Android 13). These meta tags are really old and aren't really needed if you have a manifest. 

This was fixed in 4.7.12 Beta 1 👍🏻

Thanks, I'm seeing that too. We'll get it fixed in an upcoming release.

The REST API is a JSON-based API, it'll always return JSON.

It sounds like an odd request from your payment gateway, but it's probably not suitable to use the REST API for this.

2 hours ago, MMXII said:

So this means there will be an option to enable/disable these features? Nice! What about redirecting? Which cases does that cover?

Yes, it's more for those that use SSO and have external member management systems. You can have the buttons on the account page link to an external URL.

Hi,

That is the front-end module only that you're disabling, it has no relation to tasks or other support functionality that may be running. You could for example have the front end module disabled but use POP3/IMAP integration where the Support desk still needs to function in the AdminCP. 

4 minutes ago, Nathan Explosion said:

You should be doing your checking against the following instead, as this is the FQDN of the endpoint the suite connects to...

remoteservices.invisionpower.com

This is not correct. invisioncommunity.com is the right domain for the Marketplace.

Test https/port 443 though. If that still fails you may want to do a tracert or something to figure out at what point the connection is failing.

The TLS version only matters for the login in process where our servers are sending data to your server.

This error is a communication error without outgoing requests from your server to our Marketplace. I would make sure that your server can communicate with invisioncommunity.com, you could check this from command line, or ask your web host to if you're not sure how to.

A fix for this issue will be available soon after testing has been completed.

This should be fixed in the next 10-15 minutes.

2 hours ago, PatrickRQ said:

Was about to post the logs you requested but I assume you do not need them anymore?

No, thank you. We've got an issue open and we'll improve the handling for this situation in a future release.

I appreciate it's frustrating but unfortunately this isn't an issue we can solve for you.

I've attached the response we're getting during the login process, with a 403 HTTP code. Something on their side is blocking the request, you can ask them to whitelist the request to the URL Marc mentioned above.

marketplace-response.html

Thanks for the follow up.

That helps explain the issue you're having. When you're updated the allowed IDs in the __construct() method, the \IPS\Member object has to be instantiated in order for that code to run. This happens automatically when using this code has a front/admin session available in normal use on the front end (which is why we're all expecting it to be working).

Solving this (although not pretty) would be as simple as putting this in your code before you load the member.

new \IPS\Member;

We were able to see some other logs and identified the issue. It's specifically related to a customer having their card/payment declined by PayPal then trying to execute the same transaction again.

We'll make some changes for a future release, but they still won't be able to purchase if their payment is being declined.

We've used this approach in a lot of plugins, so I know it's working properly. Make sure that you actually have a `remote_id` column created in the `core_members` table.

It may also be worthwhile to show the log from the system log page in the support section. The JSON is not a real error.

Although, these days we would recommend keeping track of SSO data in your own table so that you're not modifying core tables.

You cannot save template logic in a theme setting and expect it to work when you include it. It has to be in a template and called properly as a template.

1 hour ago, Adriano Faria said:

So to confirm: I can't use it like that? From now on, I'll need to use a hard-coded prefix, right?

If you have a setting to change the cookie name, it will no longer load the language string explaining what the cookie is on the /cookies/ page

Join the event, then you won't see it 😁

We're getting a 403 response when sending data to /index.php?app=core&module=system&controller=marketplace. Something on your server is blocking those requests.