Jim M

I would advise checking for .htaccess or local php.ini files in your installation directory which are implementing PHP 5.6. A server can run multiple versions of PHP and often there are files like this present setting specific directories to other versions. Regarding the original issue, this is a server problem (as Marc mentioned). You mentioned GoDaddy was no help, was that in relation to the PHP version issue or this? If the latter, I would suggest going back to them and asking them to re-investigate. If you do have mod_security enabled, have them temporarily disable to test.

Setting the storage engine to InnoDB will indeed help with performance. However, it may not be the end all bullet. You will want to talk to your hosting provider about changing your tables for you to InnoDB. I would also recommend disabling any third party applications/plugins and switching to an unmodified theme when evaluating performance. This will allow you to set a baseline for your performance on the core software and then evaluate the third party add-ons on top of it one-by-one. It could be one of these third party add-ons is not performing well on your server or is expectedly doing something that is a little more resource heavy. If none of the above helps, you will want to re-evaluate performance with your hosting provider with all third party items disabled. If the hosting provider finds something very specific which is a software error or slow query. We would require the proper logging to diagnose. However, generally, performance issues typically lie on the hosting side of things and they have the tools/resources to help you resolve them.

If your links contain index.php and are not being rewritten to exclude it, you would want to check the Rewrite URLs setting in ACP -> System -> Search Engine Optimization. Please ensure you follow the instructions (in the description of the field) to apply the .htaccess. (please note: .htaccess only works with Apache web servers. If you run something else you will need to have a server administrator write these URL rewrites for you) With that said, the index.php should not be impacting anything from the meta tag editor. However, we would need to know the URL which you are finding these links on and if they are a part of the software or manual.

Excellent! Great to hear!

Glad to hear you were able to resolve your issue. Anyone reading this in the future, Joey_M was referring to the "Users can see topics posted by other users?" being set to disabled. Setting it to enabled will then let users see topics by other users. This is found by editing the forum's settings and it is under the "Permissions" headline:

Do you mind providing the two URLs that you see in your browser when you see the variable titles? (Doesn't have to include your domain)

While they may be staff, simply because a user is an administrator or moderator, does not mean that they have permission to access a forum. Just like any group, they would also need access to the forum (and/or parent forums) for that topic. Could you please provide the forum and group in question? If your access details on file in the Client Area, please also update those.

Excellent. Glad to hear you found the issue and all is fine now!

While we do not have an official integration with Integromat (i.e. in our Community Enhancements area), I believe they simply use our REST API to initiate these commands. You may wish to reach out to them for more information on what they require to send requests to our software.

This would be permissions on the forum (and/or parent forums) which the topic is in that you're attempting to promote. The message is essentially warning you that you are sharing an item which is not available to guests (and possibly other groups) so they would see a prompt stating they don't have access and need to register/login. You can read more about member permissions here: https://invisioncommunity.com/4guides/security-and-rules/member-permissions-r305/

That would be variable on your server, I'm afraid. With that said, it is not a terribly long process but is not super quick either. It looks like something may have gone wrong there as the progress bar is not appearing correctly. May wish to ask your hosting provider if you use mod_security as it may be blocking the request there also with a permission denied (403) message. If so, you'll want them to temporarily disable to test this.

There would be several folders in our software so yes, there would need to be folders under your "forums" folders where your software is installed. The files listed there are not related to our software.

If you deleted a bunch of files, getting the full set from the Client Area is the only way to ensure that you have all our files. It would be a very laborious process to go file by file stating what you need. Regarding permissions, we've provided you with the specific folders which require writable permissions. The rest should be 755.

If you are afraid of doing harm on your server with permissions, I would advise contacting your hosting provider for assistance. If there is a concern elsewhere, please let us know.

Our folders structure can be found in the download in the client area. Regarding permissions, the following folders would need to be writable on your server. Typically, this is 777 but if you run suPHP or suexec, it will be 755. I'd recommend contacting your hosting provider to find out if you're unsure: applications datastore plugins uploads and all sub-folders of uploads

Have you recently changed from HTTP to HTTPS? I would ensure that you disable any server redirects (including CloudFlare) and ensure that your community is setup properly for HTTPS by follow this guide: https://invisioncommunity.com/4guides/advanced-options/configuration-options/using-ssl-https-r273/ You can update access details by going to the Client Area -> Manage Purchases -> click your license -> Review/Update Access Information.

Could you please update the access details on file in the Client Area? I can then take a further look at what is happening here.

You would need to ensure your datastore folder on your server is writable. Please ask your hosting provider if you are unsure what this is. Typically, this is 777 but if you're running suPHP or suexec this may by 755.

It looks like you opted to go with our recent recommendation and change login from usernames to email addresses. You mentioned in your statement that they are using a username. Do they get the error when using email address? Is it giving an error of incorrect credentials or just redirecting?

I see that on October 3rd there was an issue writing to the datastore for quite a while. Has that fully been resolved? I also see that you're running CRON. Have you contacted your server administrator (or hosting provider) to ensure that there are no errors there and the CRON command is running once a minute?

Did you remove all database tables in the database before performing your database restore? Sometimes I have seen some pretty wonky results from not doing this with MySQL. You will want to adjust what @Adriano Faria provided for your table prefix but that is the table schema and should allow the upgrade to proceed. Also, just a note, I edited your post to say v4.5.2 to 4.6.7 🙂

Could you please try clearing your browser's cache? Additionally, after you clear your browser's cache, could you check to see if there are any errors in the browser console? (most browsers can view this by going to F12 and then console tab) If you require further assistance, please update the access details on file in the Client Area and we'll be happy to take a look for you.

Excellent. Glad to hear you've found the issue.

Please be advised I have moved your topic to our Community Support forum for help from the community as this would require customization and further details that are outside our scope of support.

Please switch to an unmodified theme and check if the issue still exists. If so, this is likely your custom theme and will need to be resolved by the author. If you are the author, you will want to manually compare the templates modified to their unmodified counterparts to find the missing code or issue.