Jim M

It would have been in the red box on the page mentioned 🙂 . Could have just been at the right time. Unsure if you didn't see it honestly as it would have been displayed to anyone there.

/admin/upgrade . Showed it right there on the UI.

Going to the upgrader now, I am seeing the below: The error reported was: session_start(): Failed to read session data: files (path: /var/opt/remi/php81/lib/php/session) You will want to check your PHP session configuration as it cannot read/write to the location there. You will want to ensure it exists.

Did you recently upgrade PHP as a part of this process prior to running into the error? It could be that PHP sessions are indeed not configured properly for that part of the error. You would want to check the directory which they are stored and ensure that it exists and is writable. If that all checks out, I would confirm what Marc stated about crashed tables.

This would likely be coming from your PHP or SMTP configuration. We do not set anything outside of what you see there for email sending.

I would advise contacting your hosting provider then to see what is happening on the server. Ultimately, I would think that something is happening on the server to have this happen. If they are unsure, you can also do another restore of your database and simplify your environment. Disable any third party applications/plugins, integrations, APIs, etc... Only have the core software touching your database.

Sorry, let me rephrase what I meant. After you did the restore, did you run that again and that is when the data disappeared again?

Does the data disappear when you run the fix on that?

You're more than welcome to make this suggestion, as mentioned in my comment above. Please do so in the Feedback forum so it does not get lost. While I get what you're saying that there could be room for improvement (what software doesn't?). If there was a core only issue, we would definitely be seeing a lot more of this. The fact that we aren't, may be specific to any number of factors. We need an example that doesn't go away when we remove third party influences to completely determine the issue. To make the analogy more realistic, it is akin to Ford allowing customers to choose a VIN via a software. The software doesn't allow conflicts. Then an aftermarket source then allows changes to that VIN, which then creates conflicts.

When you create a Child theme, the Parent theme's CSS files will now be in the child. This means that if you make any modifications to the Child's theme CSS files, you could be removing the parent theme's CSS. You may wish to create a CSS file called "parent" in your Parent theme and "child" in your Child theme. You can then use CSS as you are wanting to here. In the example above, the white color is in my parent theme CSS file and the black color is in my child theme CSS file. I am able to use cascading just fine 😉

This is still an open issue. I'm afraid, we cannot provide an ETA of the resolution to this at this time.

Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.

You do not have permission to post in those topics. Your groups needs permission to move the topic there.

Why do you need to review every single member who registers? Why not just do email validation and moderate the users first post if you're worried about someone coming in and doing harm? There's no reason to "jail" someone until they've done something wrong. Especially, if your community is starting out, you don't want to put more barriers on your new users. Personally, I would just let them register until you're met with a reason to stiffen up your community registration process. Would state that a vast majority of our clients do not use administrator validation. It is there for an extreme case of either misuse, or you only want to cater to an extremely small niche and need to validate the registration form before letting them in. For the latter, they have a set of trusted users doing that or are overseeing that themselves as the community administrator till they have a full set of trusted users. You may wish to review our recommendations/statements in your Feedback topic regarding this 😉 .

We intentionally are not getting involved in this. If you haven't, you would want to read through the topic here for explanations: https://invisioncommunity.com/forums/topic/475077-marketplace-closure/

Are you able to provide a screenshot or link to what you're seeing? We can then advise accordingly. Are the topics themselves already archived by the software?

Can’t use PHP 5.6 with latest release of version 4. PHP 8.0 or 8.1 required. Would also recommend a direct upgrade to latest as there could be bugs in the upgrader in 4.1 No license issues currently so might be a temporary connection issue or something on your hosting side possibly.

Keep in mind that there is no feature to require administrator approval. There is the ability to require moderator approval. If you mean that, then you can do the below: ACP -> Members -> Groups -> edit group -> Content -> enable "Require approval before content shows?"

Think he may be referring to Open Graph metadata that appears on social media when you share a link. That default image can be edited in ACP -> Customization -> Icons & Logos -> Default Share Image.

That is built via our Pages application. The UI is custom built though by our team so would require a customization to get something similar but the nuts and bolts behind it are available in Pages.

Would look to see if the images are attached to the post itself rather than just copy/pasted the image URL. If the latter, those would not be updated by the system.

Sticking with our car, real-world analogy regarding third party errors, it's a bit like putting a nitrous on your Ford Taurus and then blaming Ford when your engine starts to have issues. It's not Ford's fault because the engine was never meant to have nitrous on it. If it's an issue on our end which is happening, we will certainly fix it. However, if there is a third party add-on or external force causing something to happen in the software which shouldn't. It's not really in our scope of support to apply a fix there. Certainly, the author of the application/plugin could make a recommendation to us though which we may execute if there is an improvement we could make. However, our recommendation to fix the issue would simply be to no longer use nitrous 🙂 .

Product renewals can also be purchased in interval renewals. However, it is done differently as the two are different.

Saying that there should be a generic fix is also kind of like saying, "just patch the tire" but we haven't found the leak yet. With the above examples, these were due to third party add-ons. I actually attempted to recreate this for over an hour on default test installations when the first report from SJ77 came in and could not reproduce it via the default software, even while mashing the submit button of the register form like a mad man 😄 . While I don't want to say it's not possible, as there's clearly evidence of it, there may some outside force, some strange action, etc... that we need to know about before we can patch whatever is being caused here.

I am not quite sure what you by "stack." Could you please clarify? As subscriptions, you can only purchase 1.