CoffeeCake

I'm sorry, I'm not familiar with what tools IPS offers cloud customers for maintaining DNS entries. You'll need to make the edit with whoever runs your domain's nameservers, and if you're seeing that message, it's not Google. While you may have purchased your domain through Google, you probably have custom nameservers setup. If IPS doesn't offer control of your nameservers if they are maintaining them, then you could move them back to Google with IPS' assistance on the necessary A/CNAME records used to enable CIC.

After converting our community to 4.5, we received almost unanimous feedback that the moving of these links was a crime against humanity. I'll be posting a free plugin on the Marketplace that restores all that is right in the world.

Short of creating your own migration script, the only way to revert to a previous version is to restore from the backup of the filesystems and database you took just before upgrading. This means that any changes, new content (new posts), etc. will be lost and things will be back to what it was when you took your backup.

I asked this question in the past, yet it is apparently an intentional design decision by IPS for Stripe's fraud checking. https://stripe.com/docs/disputes/prevention/advanced-fraud-detection Seems like maybe only nexus pages would be a better choice.

You should also have the option to make DNS entries instead. I'd recommend doing it this way. https://support.google.com/a/topic/1409901

I'm not sure if I'm understanding elastic's documentation, yet I don't think 7.6 is getting updates or bug fixes anymore. It would seem that it would be prudent to stick with 6.8 until this is resolved. They do occasionally have security fixes, and 6.8 is still being patched.

When I search for a member's display name in the ACP, if there are many members that have that portion of their name within either their e-mail address or display name, I only see the first 50 matches and in almost all cases, never see the exact match appear. To clarify, from the search bar at the top of the ACP. Please return any exact matches at the top of the list. Reporting this as feedback, yet since I can't access the member I need to access, I'm wondering if it's a bug. To find these folks, I have to go to the member list and use the search on the right hand side to limit and scroll through all results.

After testing, this is the approach I'd recommend for larger sites. Make a copy of your settings somewhere, uninstall just before the 4.5 upgrade, upgrade, and then reinstall. This stopped the entire issue of migrating data. Short of the above issue, it looks like this got us over the hurdle.

We moved forward with our 4.5 upgrade and uninstalled this application in 4.4. Now, when we go to our installed applications, the application is listed at the bottom as not installed with a button to install it. Pressing the install button says that the application is already installed. Trying to install again from Marketplace says that the application must first be uninstalled. To get past this, we removed applications/autowelcome from the file system and then went to ACP > applications and removed the "out of date" application at the bottom.

You may want to open a support ticket and/or re download and upload the IPS files to your host.

No, it's not a terrible idea on its face, and I don't think it's fair to characterize it as such. IPS is now dealing with the reality of the concerns raised during the beta. If I, as a customer, had a marketplace available to me of supported, quality products, that IPS took ownership of, controlled, and gave me assurances would be supported long term, I'd have no issue here. I'd just open up a support request, let you know that something was not working right, and IPS would help me fix it. Now that you recognize the degree to which the items available via Marketplace are not following your best practices, I'm glad you're doing something about it. Please continue that effort. It improves the ecosystem. Yet, I think we'd be better served if you owned the shortcomings of the execution of that strategy, rather than characterizing those who alerted you to the issue in advance of having some sort of agenda. I also think you need to be in better touch and communication with your stakeholders regarding your roadmap for major changes like this and involve them in those conversations so you can get a better sense of the impact that may be difficult to see from your perspective. We could have likely had a thirty minute call that could brought to light these issues and concerns earlier on in the process and have helped guided your direction and execution. I think IPS would be well served to seek out and embrace those sorts of partnerships with customers. Maybe that's the goal, yet the state of Marketplace in 4.4 and below was exactly the opposite, and you're now catching up. From our vantage point, the Marketplace was a hodgepodge of questionable practices, of which there was no assurance of quality, stability, or functionality. I'm glad higher degrees of scrutiny are being placed on new offerings, and that you're seeing just how that was the case, yet the purpose of my opening the topic is to ask what happens when your best of intentions fail. This is an example of where there's a clear lapse in the considerations being made by reviewers. This is an issue IPS needs to address to reach your goal. Part of the review plan should be install/upgrade/delete this on a large sized community. We purchased your software because it was modifiable, and with the intent to modify it ourselves to suit our community's needs. We know that what is good for our community may be completely different from the needs of other customers. And to be able to create modifications, we do need the access to developer documentation and to the community of developers that is currently available only to those who contribute Marketplace resources. We purchased modifications from your Marketplace in 4.4 because we were able to see, understand, support, and take over maintenance of those resources without depending on someone else. Now that this isn't the case, and we don't yet have the necessary trust in the direction the Marketplace is shifting, we've had to quickly reverse course and strategy to making the modifications ourselves. We went from two custom modifications in 4.4 that weren't from the Marketplace to ten customizations we've developed ourselves in preparation to migrate to 4.5. In addition to taking on that technical debt, we're being limited in learning from the collaborations with others. That's not right. For the Marketplace to work for communities like ours, we need assurances on the following things: IPS' commitment to amend its review processes to look for issues that manifest themselves in larger communities (i.e. communities with millions of rows in each core table) and for issues that occur in the install, upgrade, and removal of third-party resources. Support for circumstances that arise from missing an issue on the IPS review of a third-party product (i.e. "We missed that this botched the conversion process in our review, so we'll provide support to you to fix the state it's in and work with the developer to get it working") Transparency in the expectations you place on developers that are viewable to individuals who have not released an item on the Marketplace (i.e. where can I learn about developing background tasks?). IPS' assurances to address the very real, and unfortunate reality of a third-party developer being no longer able to support or update a resource purchased through the black-box of a Marketplace. (i.e. We can't have a dependency of Developer X being the only one with keys to our enterprise.) IPS' commitment to notify self-hosted clients well in advance of major strategy changes such as these in the future. We would have significantly amended our budgeting and resource allocation had we known about this change to the Marketplace in advance, and you lost a great deal of the trust we put in you as a vendor by failing to do so. We're left with egg on our face making up for this lapse in the eyes of our stakeholders. We see ourselves as having a symbiotic relationship with Invision, where our respective successes help grow and support each other. We want you to succeed in these ventures as your successes enable ours. Yet we need to have a trust in our partner to ensure that our interests are protected. Doing so positions us to be advocates for your company and solutions, over simply being a client looking for the next best thing.

It looks like you have the Dev SDK installed. You'll want to run your conversion on an instance without the Dev SDK.

I'd recommend having nothing but IPS files in the folder where your forums live and handling any exceptions through nginx configuration. You'll want to ensure that the forums application is set to the default application within IPS. Everything within forum should point to the index.php in your IPS install.

I believe that's <header>, so #ipsLayout_header is likely what you'll want to adjust. You can use Google Chrome, right click, and choose inspect to see the CSS properties of a given area of your site.

You may want to open a support request and ask for assistance with this. Have you pruned members?

PJStalls, Some questions: Was vBulletin installed at example.com/forum/ (the singular of forums, with no "S")? Where are you installing IPS? At example.com/ or example.com/forum/? Have you made any adjustments to IPS furl.json files? If your vBulletin URLs were example.com/forum/showthread.php?t=123, and IPS is installed at the root of example.com and you've made no modifications to furl.json files, you'll need an additional redirect rule at the nginx level to redirect /forum requests to /forums (i.e. example.com/forum/showthread.php?t=123 gets redirected to example.com/forums/showthread.php?t=123). IPS uses the plural "forums". Here's a good guide on nginx & php-fpm. It's a bit dated, but a good starting point.

It would be nice to show something along the lines of "a new version has been submitted for review" and "Developer action required" or "IPS review pending" as statuses to help end users have visibility into this process.

You won't see anything related to the old URLs anywhere. They are hard-coded into the converter files. If you are self-hosting, you must install your production environment with the converter files included. That's where the magic happens. You should have no vBulletin files in your web root. Make sure they're all gone. For the conversion, you only need the vBulletin database until the conversion is complete. If you had any sort of modification installed with vBulletin (think vBSEO), you'll need to handle the redirects back from the rewritten URLs to the out of the box URLs (showthread.php?t=<old thread id>, as an example). Your IDs in IPS will be completely different from vBulletin, however they will be redirected when someone hits your old URL. Are you sure your nginx configuration is correct? Unless you are installing IPS at /forum, you should be sending everything to index.php, not forum/index.php.

@Chris Olson, you'll need to adjust the CSS (you can do so in custom.css easily for your theme).

This is also what we did, however then certain positive reactions, used out of context, became the negative. However, the original request + plus a restriction on private messages is still a need.

Michael, thanks for the offer. Happy to test, and your assistance is not needed to fix anything. It's a test environment that mirrors our production, and we wipe it clean and start anew over and over again as we prepare for 4.5. This thread was more of a general discussion on what's the plan to address these sorts of issues from the standpoint of the curation and management of the IPS Marketplace.

Totally understand. You're not the only one doing this by far. See here for some strategy discussion, and sample code that worked at ~1,000,000 records. You may also want to look at the UPGRADE_MANUAL_THRESHOLD constant as well and throw up the option for a query to run straight at the SQL level.

Absolutely. Have seen this issue as well. We'd like to see the options to restrict posting expanded to optionally include using reactions and private messaging.

There are lots of ways to handle these things, and this should likely be a part of the plugin/application upgrade framework. IPS' own converters use these practices. It's not a foreign concept. In an ideal world, we'd have something we could run on the server directly via shell prompt. We encountered this issue regularly in the past with any modification that would touch large tables, and in our installation, we have a lot of really large tables. That's why we now test for it and know to look for it. The best practices, developer documentation, and testing should all reflect the necessary practices that will address the needs of communities at any scale.

That's a great question. I couldn't find the answer in the developer documentation, so I'm really not sure. I'm asking here to find out and generate a discussion for the benefit of all. I should be able to provide a link to you right now in those docs that says "here's how to handle background tasks," but I couldn't find it. That's problem #1. Problem #2 is that absent that, and absent the ability to inspect resources in advance of install, we now cross our fingers and see what happens. At the rate the plugin was converting things (50 members at a time, ~1,000,000 members, at what looked to be about 1 second per 50 members) this would have taken just shy of 14 hours to complete this task. I can think of two solutions: Process the conversion as a background task that runs regardless of whether or not a connection is available. Prompt the administrator to run SQL directly in the background as various parts of the 4.5 upgrade do for long running queries, and press continue when complete. It's insane to create a dependency that 20,000 calls to a web server need to execute flawlessly or else the process breaks. Looking at the code on my test machine and examining the upgrade.php script that runs, this could have been handled with two queries. One that would have inserted a row per match from core_members, and another that would have dropped the column from core_members. Something like: INSERT INTO autowelcome_members (welcome_member_id, welcome_sent) SELECT member_id ,member_welcome FROM `core_members` WHERE member_welcome = 1; ALTER TABLE `core_members` DROP COLUMN `member_welcome`; This used to be a problem I owned. I could download a plugin, look for things like this (we're primarily interested in 1. will it scale?, 2. is it secure?), make any necessary revisions, and we'd be happily on our way. Yet, now IPS has taken that ability away from us. I have to go digging around the filesystem of my test install to find what this thing is doing, whereas before I could look straight at the tar or xml and catch it ahead of time. The above query runs in under 3 seconds on my install. 3 seconds compared to 14 hours..... If IPS is going to take on the responsibility of looking for issues in lieu of allowing us pre-install download and inspection, then the recoverability of upgrade/installation scripts is something they should be examining for potential issues.