Jim M

Did you associate your Facebook account to your “forum” account? Did it update your email address on the account?

These would be the background tasks that were triggered from the upgrade so these would need to complete. You are still in the version 4 upgrade process.

At the time of support, our technicians would require read and write access. As previously mentioned, you would need to be fully on the version 4 platform. The upgrade and it's background tasks need to be completed. However, if at time of support, it is deemed that poor data from version 3 is causing an issue, that may be outside our scope of support. That is entirely rare but for instance, if a plugin from version 3 corrupted core data and got upgraded to version 4, that is not something which we would support. As well, for instance, if the wrong collation was used during the upgrade of version 3 data resulting in bad/corrupted data in version 4, the instructions would be to re-do the upgrade with the right collation, etc... Unfortunately, I cannot provide you with all cases as mentioned, it would be highly case-by-case but these are some examples. If things are looking good with your upgrade, I would not even bother worrying about it 🙂 .

For any support requests, we require access to the ACP and FTP/SFTP. I am unsure what you mean by list of things that you have to do prior to evaluation or what you mean by "evaluation"?

Just copy/paste the URL in your post 🙂 .

It will not change that a user can only have one subscription at a time but will improve the experience for up/downgrading a subscription during that expired process.

This is currently intended as an individual can only have 1 subscription at a time. An administrator would need to renew the subscription if they wish to move forward. We are aware of this may not be ideal so in 4.7, there are some improvements to this process.

The upgrade needs to be completely finished, which entails the background rebuilding tasks. We then would support the core software on version 4. If there is issues with the data upgraded from version 3, that would be evaluated on a case by case basis if it's an issue.

There are built-in and custom advertisement locations in our software. You can read more here in this Guide:

The system converting BBCode into HTML would be expected. The URL used would indeed include code there for the base URL. The steps which you mentioned there and the error stack trace you've provided, are not something which I can reproduce. The conversion from BBCode to HTML works without issue and the base URL is evaluated fine. The stack trace which you posted is coming from a rebuild task in the background. If you go to ACP -> System -> Dashboard -> Background Processes, you likely have a lot of tasks coming from the version 3 upgrade of rebuilding posts.

Please ensure that you resolve the 500 error in all directories as I am still running into that in some other areas.

Sorry, pointing out where our code lies is outside our scope of support. Is this a rebuild task resulting from an upgrade of a 3.x site? If so, you are still in the process of an upgrade, I'm afraid. In this particular case, the URL being attempted to access is invalid thus throwing the error.

Sorry, your ACP is requiring email but we have only a display name.

We would need to look further into this for you, however the access details on file appear to be incorrect or missing. Could you please update these details by visiting your client area, selecting the relevant purchase, then clicking "Review/Update Access Information" under the "Stored Access Information" section. We look forward to further assisting you.

To clarify, there may not be a write issue per say with permissions but the speed/performance may not be what is optimal in the time there so thus there is indeed a write performance issue. You can, of course, check this by disabling template disk cache as it will generate this on demand from the database instead.

It could be that the folder there is using a different version of PHP or a configuration element has not been passed. This is something you'll need to work with your hosting provider / server administrator on, as hosting support is outside our scope of support.

I've seen this in cases that the template disk cache is having write issues or that the cache is outdated. I would recommend inspecting whether or not that you require template disk caching if your server cannot write. There are also quite a number of plugins/hooks being loaded for these errors that you may wish to check/disable and see if they are involved with this error.

I'm afraid, we are unable to schedule a time frame in order to perform support actions in. We will need the items in place till we inform you that we no longer require it.

You'll want to check your server's configuration and what the Internal Server Error is. Any file I drop in your /admin folder is resulting in a 500 ISE, even our basic requirements checker: /admin/ips4.php

You would need to restore any modified files, fix or disable third party applications/plugins logging items, fix the database table engine, and anything else mentioned under support for us to move forward with our investigation.

Unfortunately, we have never officially supported NGINX. Any configurations, including rewrites, are solely on the server administrator to perform if you wish to use it. Throughout your use of unsupported items, you will need to modify your configurations if they break (whether that is from upgrade of NGINX itself or our software). If this is something you do not wish to perform, currently the only options are to use Apache or switch to our Cloud as these will come with supported resolutions for you. If you want to see NGINX support in the future, like anything else, you're more than welcome though to post any feature suggestion changes you wish in our Feature Suggestion forum. I understand you are frustrated by the lack of official support of NGINX but an explanation has been given to you by our staff and your peers plus you have voiced your opinion on that. You're welcome to post here to receive support on your NGINX configuration in an unofficial support capacity but anything else has run it's course and this topic will be locked. Thank you for your understanding.

Please place the admin folder files from the Client Area then use the recovery mode mentioned here to disable all third party items which may be creating an issue here: If you continue to have issues, please leave the admin folder from the Client Area in place and we can take a look.

Unfortunately, the only solution would be to get the community in a place which we can investigate further. There are no means to disable one background task.

OK, please let us know if we can be of further assistance.

I would recommend clearing any custom edits as Nathan mentioned, something has changed it there 🙂 . Glad you found the issue though!