LiquidFractal

Upon further examination, I think I can save you some time. 🙂 I think this happens when ips4.php is run on a site which does not yet have a mySQL database configured. I'm using DirectAdmin, and I notice that once you create a first DB, only then does phpMyAdmin become available as a clickable button, so I think this has to be set up for mySQL to register with the ips4.php script. To this end, I ran the script on my production site (which obviously has all this set up) and everything displays fine. Hope this helps!

I recently upgraded to 4.7 and 8.0.x on my business site, and everything is running fine. However, I tried it first on my test site by first upgrading to 4.7, then disabling all customisations, then upgrading to 8.0 and re-enabling things bit by bit and reloading the site - which helped me discover one or two apps/plugins which broke the upgraded test site so I could delete them on my production site. I tried 8.1 and it was working for a while but I now have to reinstall my test site as there are strange problems with trying to access the PHP *.sock file (I think switching FPM packages too often does this?). Anyway, that's probably a general procedure to follow when making such important site updates. Strangely, I ran this on my newly-wiped-clean test install site and while everything's in the green, the PHP script seems to omit everything below server requirements: Just FYI: perhaps this is due to PHP 8.1.8?

Hello, I need to reinstall my online test install and need to reset its URL ASAP - I'd actually like to reset it to a top-level domain: https://www.liquidfractal.space. If someone could sort me out as soon as possible that would be great. Thanks!

Whoops! Obviously meant to say MariaDB 10.6.8 🙄 lol

For what it's worth, I'm currently running IPB 4.7 on MariaDB 4.6.8 and PHP 8.0.8 with no issues whatsoever. Because my VPS allows me to switch PHP versions with the click of a button, I've even done some preliminary testing with PHP 8.1 and have had no problems with that either.

Ahh, so. Many thanks for the clarification!

No, all good - I was checking my apps and plugins en masse by clicking through to the Marketplace interface, which apparently doesn't have all this information.

Actually, as with my other post there is no explicit mention of 4.7 compatibility in my Marketplace view of your app. If it is then it is, but I'm just saying that I don't get that view of your product. I get a long list of changes with 2.2.0, but nothing like what you attached. FYI.

Really? I'm not seeing that. I'm seeing: No overt mention of 4.7 compatibility. So there's that.

Sorry if I missed this but I was checking a list of apps and plugins, some of which (rather frustratingly) led to "configuration error" pages so, like you, I was getting a bit impatient. But hey, you could always just reply with "yes" instead of including a screenshot if that helps.

Any word on 4.7 compatibility?

Is this 4.7 compatible?

Any word on 4.7 compatibility?

Any word on 4.7 compatibility?

Any word on 4.7 compatibility?

Any word on 4.7 compatibility?

This would be exactly what I had in mind. Thanks for listening! 👍

I've had the same issue for months and months now - I have to disable ICE in order to add apps to a Club! I've given the version number and other applicable information...and nothing for ages. This app is important to my business functionality, but I'm going to rethink paying for this app if the developer doesn't at least remind us they're alive!

This has been on my mind for some time now...it would be great to have a bit more more granular control over the subject lines IPB automatically sends out for things like comments, replies, etc. For example: when a client replies to a project discussion thread, I simply get the title of the forum thread X in my notification email. It would be a bit clearer if it read "Reply to discussion X" or "Comment on X" or something like that. I think it would be good to change this, but even better to allow site owners to configure these things wherever possible.

The one other thing I wanted to mention: unless you really really like running this procedure every so often to keep your DB InnoDB, you want to make InnoDB the default storage engine for your DB so that all future apps and plugins will create InnoDB tables instead of myISAM. To do this, there's some helpful information in this thread: Or, if you have a managed VPS (or something along those lines), contact your provider and ask them to do this for you.

First off: I am not a SQL expert of any kind, so I will not field questions about this procedure - I'm just sharing what I just did on my website to switch over DB tables to InnoDB as per Invision Support-page recommendations. The code isn't mine - I lifted it off the web somewhere. If you've been wondering how to switch over your MyISAM tables to (what I understand as) the more stable and optimized InnoDB storage engine, look no further! It might be best for everyone to do this anyway, as I read somewhere that MyISAM is now deprecated and, I suppose, on the way out eventually(?). Anyway - to do what follows you will need access to phpMyAdmin or some similar interface which allows you to perform direct SQL queries. Make backups - I do not assume any responsibility for anything that breaks as a result of this! First, go in to phpMyAdmin (or whatever) and make sure your Invision DB is selected. This procedure assumes that you have one DB which is dedicated to IPB with no other app tables in the DB (it may still work, but I have no way of trying it out and I don't know enough about SQL to be sure it will work in a shared DB). In the SQL query box, run the following code. Be sure to replace YOUR_DB_NAME_HERE with the name of your Invision DB: SET @DATABASE_NAME = 'YOUR_DB_NAME_HERE'; SELECT CONCAT('ALTER TABLE `', table_name, '` ENGINE=InnoDB;') AS sql_statements FROM information_schema.tables AS tb WHERE table_schema = @DATABASE_NAME AND `ENGINE` = 'MyISAM' AND `TABLE_TYPE` = 'BASE TABLE' ORDER BY table_name DESC The output will include a list of SQL commands linked to your existing MyISAM tables. Each line, when run, will convert the MyISAM table in question to InnoDB as per the following example: ALTER TABLE my_table ENGINE = InnoDB; You can run each line separately, or (recommended) run batches of them at once. Just make sure the syntax is correct for each line (phpMyAdmin will truncate longer lines, but will show you if a line has improper syntax). You may need to do several passes in order to switch over all your tables. My procedure was as follows: I ran a series of ALTER TABLE statements at a time, then re-ran the SQL query in the above box to get a revised list of remaining MyISAM tables. Then I'd run the next batch of generated ALTER TABLE lines, and so on until running the SQL query block above generated no results (which means that they've all been converted and you have no more MyISAM tables). That's it! Browse your DB and you should see all of them running under innoDB. If there's a more professional and streamlined way to do this (especially for very big websites), I encourage those with the knowledge to post - again, I'm just posting what worked with my VPS. Hope this helps someone out there! I swear I can see a definite speed increase on my site as a result of switching!

I'm finding the default CKEditor font size a little small with my current theme and was wondering if there was a way to tweak the default size and bump it up slightly? Thanks!

Awesome...thank you @HeadStand!

Hey Daniel...actually, no. In fact, I hadn't had time to explore Custom Email Wrappers until just now (because of this conflict). But I just now finished creating a sample template (the same as @HeadStand's in her PDF), and it worked just fine. So, no errors at all...just the conflict. And just FYI, I'm on IPB 4.6.12.1.

Thanks for replying HeadStand! There are no "errors" as such: when CEW is enabled I can still use Email Drip Campaigns, and emails are still sent out when I start campaigns. The issue is that while elements in the email (e.g. emojis, quotes, links, etc.) are fine, there's no email wrapper formatting whatsoever. I did troubleshoot through every app and plugin on my site, and can say with certainty that I've narrowed it down to this conflict. Everything reverts to normal when I disable CEW.