CoffeeCake

I don't use Commerce extensively, but I'd be surprised if you can't set up a mailing list that includes only people who have purchased a given product as a solution for that. Alternatively, the "product" that you sell could be a download of a PDF with the link/instructions to join that they're given access to upon purchase (if it's something like a known meeting ID in WebEx, etc.)

Could a workaround possibly be to create a product in Commerce for each event and then link to that product in the store in the description of the Calendar entry?

Ah, yes. Likely so.

We were able to upgrade from the latest version of vBulletin 3.8. Not sure if there's a particular 3.x requirement, but we did not have to upgrade to 4 or 5 first.

Will reiterate that you'll want to test, test, test. When you're done that, test some more. I'd recommend creating a test install and inviting members that are in both communities and those that are only in one or or the other to be involved in the testing process to help find issues. We did a very large vBulletin 3.8.x to IPS conversion and in spite of many tests, we still were surprised by some issues when we moved the production site. Those issues have since been reported and presumably fixed by IPS, yet I can't overemphasize the importance of testing and of engaging your most passionate members in the process to help manage that change. One of the things you'd want to test for something like this is how links from the existing vBulletin install are redirected by IPS, if this is a concern for you. Redirecting old URLs like example.com/forum/showthread.php?t=12345 is handled by the converter, yet if you are merging multiple vBulletin communities into a single IPS, I imagine that this will be trickery. I'm not sure the URL redirection scheme considers thread 12345 from two installs and redirects to the right place. May not be an issue for you, but I'd test it first. Consider firstvbulletininstallsite.com/forums/showthread.php?t=12345 vs. secondvbulletininstall.com/forums/showthread.php?t=12345. How would IPS know which converter to look at when trying to match old thread 12345 with whatever ID it ended up with in IPS? If you only have one vBulletin instance to worry about ever, then this is not a problem for you.

I don't think it's the issue that you can't point to the marketplace. It's the issue that you can't download and inspect the packages directly from IPS any more. There's now a requirement that the test install have internet access and that you install things before inspecting them, and for localhost installs, you can't install and test applications and plugins published by the community (without a roundabout process of installing in test and then extracting the resource). For many communities, plug and play is probably just fine. But it's not serving the needs of those clients that have more stringent policies or requirements that they follow in the development lifecycle. Now, there's an extra step of using a test install to acquire files rather than being able to download and inspect them as before (or put them in a virtual localhost environment). The IPS marketplace should have a download button for 4.5 resources, and have its current integration as well. Go install from your ACP, or download here. That would be ideal. Just to add for context, we've purchased, downloaded, and installed a few applications and plugins from IPS Marketplace that, when tested in our local environments, we quickly identified conflicts, issues, and breaking changes that would degrade our member experience and/or simply not work at the scale of a community the size of ours. We identified issues that would have otherwise taken down our production copy and/or production installs due to things like altering the core_members table rather than having an application/plugin specific table. Whatever checks of things (if any--I'm not sure) happening at IPS, they're insufficient for our needs, and we have a duty to our stakeholders to test things and ensure they're ready for our environment and configuration. This change is an obstacle to that process. We have a workaround, yet it's needlessly causing us to install things in test and have to revert that environment after the fact when our workflow of installing in a local dev first and doing comparisons was much preferred.

Absolutely a necessity to support multiple localhost development environments and to support the download of application/plugins directly from the IPS marketplace as existed in 4.4 and earlier. The inability to download files directly from the marketplace limits severely limits those that have installations that are not accessible from the outside internet, whether that be an internal corporate install or various development / virtualized environments. It also prevents administrators and security folks from being able to audit applications and plugins prior to installation in any environment. At present, one must install an application/plugin prior to being able to review. In the past, we've purchased plugins/applications that upon inspection of the downloaded file, we found that there were breaking changes that did not follow IPS development guidelines and that would have resulted in a degradation of service in our production environment. Without inspecting those files in advance, we would have not been able to identify these issues.

Sounds good. I use support requests only to communicate with members. Not everyone has access to PMs, and other moderators can't see replies to PMs sent from another moderator. As an option, it would make it an ideal solution.

A humble request that IPS consider adding configuration for test API keys for those payment gateways such as Stripe for use when the NEXUS_TEST_GATEWAYS constant is defined as true. See this post for additional context: Doing so helps support automated testing of production data in a test install by allowing the definition in constants.php to trigger use of testing API interfaces. We had a scenario where we inadvertently charged a customer twice due to this not being documented as behavior when using certain payment gateways. Looking at the linked thread above, it seems others have encountered this issue. For us, we have important things we test involving production data and while most may not do this, having this option would help with this testing workflow and continuous integration/development. Alternatively, we'd need to make changes outside of the application and direct to the database which we'd prefer not to do.

This just got us and we accidentally charged a customer twice with a copy of our production database. It would be nice to add an additional setting for Stripe configuration to enter in test API keys, so that this flag actually works.

Along the same line, could you have it send a support request through Commerce instead of a private message?

You can look in Google Chrome console to see what javascript errors you're encountering. https://developers.google.com/web/tools/chrome-devtools/open

Most likely, you do not want to use SQL sockets with a MySQL database that's on a separate server. This will not work unless you're doing something that's rather atypical. You'll want to verify that the external MySQL server is configured to accept connections from your server (by default, MySQL only accepts connections on the same server), and that you've entered in the correct IP address under sql_host in conf_global.php. For testing purposes, you can use the mysql command from the Unix shell on your web server to verify that you can establish a connection like this: mysql -h <IP_ADDRESS_OF_EXTERNAL_MYSQL_SERVER> -u <INVISION_MYSQL_USER> -D <INVISION_DATABASE_NAME> -p You will be prompted for the password for the SQL account. Replace <IP_ADDRESS_OF_EXTERNAL_MYSQL_SERVER> with the IP address of your external server (sql_host), <INVISION_MYSQL_USER> with the SQL username you configured for Invision (sql_user), and <INVISION_DATABASE_NAME> with the name of the database (sql_database). The password you'll provide is the one configured for your Invision SQL account (sql_pass).

Poking around, it looks like you have Wordpress at the root of your home page and your base install is at /forum/. I'd take a look at your web server configuration / .htaccess to make sure that the forum/api URL is pointing to IPB and going where it's supposed to go.

Are you sure your path is correct? Your sample code above is pointing to: http://poolspaforum.com/forum/api/core/members You probably intend to land at poolspaforum.com/api/core/members assuming IPB is installed at the root of the domain. Also, do you intent to use https? You should see results once you have the correct address in your browser with something like this example using IPB's site: http://invisioncommunity.com/api/core/hello

Can the moderator approve the post in the forum in which they are not a moderator?

Oh, so to see if I'm understanding correctly, let's set up a scenario that I think you're describing: You have various forums setup, each with distinct moderators that only have moderation permissions within those forums. We'll make things up here as illustrations: Pizza Forum Pancake Forum Peach Cobbler Forum Braymond, a noted expert in established pizza circles, is a moderator only in the pizza forum, with no moderation privileges on the peach cobbler or pancake forums. New member, WafflesAreDelish, posts a first post as a moderated post in the Pancake forum which must be approved by a moderator. Braymond receives a notification to approve CrustSideOnTop's post in the pancake forum because they are a moderator somewhere, but not in the Pancake forum. Other moderator, Mrs. Buttersworth, is only a moderator on the pancake forum and not in the pizza forum. She won best pancake three times in the late 90s, and has published 24 books on the art of pancaking. She gets notifications when someone posts a moderated post on the pizza forum, of which she knows nothing about and has no moderation acccess to. Is that what's happening? If so, that's what is supposed to happen per support? That seems like a pretty solid use case that should be configurable.

You need to enable the fr_FR locale on your server. Determine what distribution of Linux your server is running and search for instructions on how to add a locale. Here's a guide for Debian: https://wiki.debian.org/Locale

Something is calling PHP code that expects that extension. It's used to encode PHP scripts to prevent you from accessing the source code. Do you have any applications or plugins installed that might do this? IPS doesn't use this, so something else is up here. You may want to back up your site's home directory and reupload a fresh version of 4.5.

No worries! Happy to help. It doesn't need to be complicated, and the good thing is you can start small and learn and modify your testing plans as your knowledge base grows. Here's the information you need to install IPS. It's the same process regardless of whether or not it's on a server in a data center, or on your local desktop: Just pay special attention to what you need to do with your license to mark a test install if you're exposing it to the internet. Here's the information you need to setup a development install from IPS: This is what you need to do to develop plugins/applications/theme hooks/etc. that can be created here and then downloaded and transferred to your production site (or you can sell them on the IPS marketplace). A good place to start Googling is learning how to create (L)AMP environment on whatever type of operating system you have on your computer. The instructions are a little different depending on whether or not you have Windows, MacOS, Linux, or something else. Look into virtualization options as well for your OS. Things like virtualbox.org work universally, and most modern versions of operating systems have some native virtualization available. For Windows 10, look into the Linux subsystem: https://docs.microsoft.com/en-us/windows/wsl/ You'll probably want something similar to whatever you have on your production server for simplicity sake. For example, choose the same web server (apache, nginx, etc.), MySQL, and PHP version if you can.

"It depends." 🙂 TL;DR: I clone a copy of my production sites to test upgrades, and some of my databases are many magnitudes larger than yours, however I have reasons to do so in my testing plans that you may not. If you can afford it and have the technical resources to do so, it's probably a good idea. If you're looking to only test functionality where old content is not needed, or if you're looking to do things like new template/plugin/application development, you probably can get away with the simplicity of maintaining a separate environment. This has the benefit of not being as resource intensive, yet without testing a clone of your production environment, you need to remember that your testing is limited and subject to change when the conditions do. Often, this is a good candidate for a local install that's used for development that can live in a virtual machine on your local computer. This is nice, because you can spin up multiple copies quickly to test out different things. If your expectations for testing are that you will be aware of any and all impacting changes to your existing community, then starting with a copy of your production site is a good idea if you have the resources to support doing so. You won't know about breaking changes in the install of a plugin that isn't adhering to IPS guidelines and makes a modification to a giant table that times out, or if migrating breaks existing permissions for users, or if important samples of previously posted content will look as you expect. A good reason to have a clone of production for testing is that you can minimize surprises when making the changes in production and pre-choreograph the process for making those changes to production. You can include things like load testing, looking at the full stack that might be involved if you have things like CDNs or third-party providers for e-mail, or storage like S3. It's also a great way to test things like impact of different versions of elasticsearch or redis. The downside can often be the cost of maintaining those environments, whether that be costs associated with server infrastructure. These costs may be in storage space, CPU allotment, limitations imposed by your hosting provider, etc. For me, maintaining things with a cloud provider that uses virtual machines makes spinning up copies quick and easy. You can script the necessary steps you'll need (changes to e-mail settings, so your test site doesn't fire off e-mails to your users unexpectedly, changing values in conf_global.php, making adjustments to constants.php, etc.), and then all that's left is making sure the test license is applied. If things go wrong, it's a few clicks to wipe everything and start again. Hope that helps!

Good question--are moderation functions available via the app?

You tease!

Hi @Kelly Hanlon, You can make adjustments via CSS changes in the form of editing the theme's custom css option, or by authoring a theme hook plugin. See here for more information: https://invisioncommunity.com/4guides/themes-and-customizations/ CSS specific info is here: https://invisioncommunity.com/4guides/themes-and-customizations/css-framework/

Fantastic suggestion! I've often thought about this when logging in, yet always forget to ask. There's sensitive information in here about our sites that additional layers of security would help mitigate against exposure.