托马斯。

很抱歉耽搁了，似乎有一个技术问题（兼容性刚刚显示为“阵列”），但现在看来已经解决了

由于苹果公司的恶意行为。也正因为你最肯定不希望其中一个市场被垄断的情况。

你描述的任务都不需要任何自定义编码，除非你想做一些真正看中的模板。此外，这基本上是为什么你使用软件产品一样摆在首位IPS，这让这样的东西很容易做到为大家出的即装即用！我想他是指以＃2页的数据库，而不是它背后的RDBMS。

开始用尽可能小的（虽然我会建议不要开始什么比2 GB的RAM下，允许一些缓存净空为您的操作系统和数据库），并根据需要随着时间的推移纵向扩展。监控您的资源使用和优化/规模，当你开始达到最大容量。你可能会被缩放你的内存资源比什么都重要（缓存消耗吨内存巨大的性能因素），因此侧重于内存可扩展性可能是要走的路。对处理能力的需求只会增加作为你的同时访客数的增加。PHP是单线程的，所以它不会从具有单个进程级别提供更多的内核中获益。当然，单独的进程中/线程可以在所有可用的核心来展开。因此，更多的内核可以处理更多的请求。你在另一方面数据库会很高兴地利用更多的内核，虽然通常的瓶颈是存储，而不是考虑处理能力，这样，即使只是一个单一的核心实例将可能做工精细为出发点，为所有AWS实例似乎提供快速的CPU（不知道的引力处理器，虽然我根本就缺乏这些经验）。当你的内核开始变得忙碌，你给他们更多的朋友一起分享工作。 (The burstable type instances are a bit of a different story it seems, but they probably will work fine too for small communities). As far as storage space goes, depending on the type of community you intend to run on it, this is usually of least concern. Well, unless you have a very media intensive community where people upload lots of gigantic files of course. Storage performance is a different beast. I noticed AWS offers EBS and physically attached NVMe SSD storage -- the latter sounds like the better performer while the former sounds more scalable (less important as you mentioned you will be using S3 storage). This is primarily of concern for your database which is random I/O intensive. I'd reckon EBS is fine for starting/small communities as most data would fit in cache memory anyway. Once your write rate goes up significantly or you start hitting a lot of non-cached data (for whatever reason) you might want to consider an upgrade there to reduce I/O latency. Which AWS instance type suits you best depends largely on budget. For a smaller budget a t3.small instance seems to provide a good balance between price/performance and offers a great scale path. With a larger budget an r5.large/r5d.large instance seems to allow for massive memory scalability while also providing great computing, storage and network performance. These are just a few examples I grabbed after a quick glance on their website, only you can decide what truly fits your needs.

因为当您已经拥有所有权限时，拥有所有这些单独的选项卡是没有意义的。在这一点上，没有什么可以微调的，你已经是全能的了！

将其添加到Nginx配置中。您可能需要联系您的主机来执行此操作。location/{try_files$uri$uri//index.php？$args；}如果您的IPS套件不在文档根目录中，则相应地修改路径：到IPS的location/path{try_files$uri$uri//IPS/index.php？$args；}

你的问题模棱两可，所以我将试着回答一些解释。如果您参考\IPS\Settings从何处获取自己的数据：\IPS\Settings从conf_global.php文件和core_sys_conf_Settings数据库表（该表已缓存，因此如果缓存中有可用的数据，它将从该表中提取数据）获取数据。如果您指的是如何使用\IPS\Settings：您只需调用所需的任何设置，就好像它是一个对象属性：\IPS\Settings:：i（）->在幕后设置\u键这是通过PHP的神奇方法\uu get（）和\uu set（）实现的。

@opentype我想您可能错过了@hippydonna线程的其余部分，我可以确认它也适用于该场景。然而，我看到了一个小问题，当你使用插件的opt-in-billing选项时，它需要用户按两次Continue按钮。当禁用选择加入计费或购买非强制订阅时，不会发生这种情况，所以这一定是我在测试中错过它的原因。我将对此进行调查并发布修复程序。但总的来说，它会很好地工作。

@hippydonna应该是这样的，但是我还没有针对那个特定场景对它进行测试。我会马上做的，我很快会回来的。

@hippydonna应该工作得很好，是的。

@Ramsesx此功能现在可用

很高兴听到您的建议，我一直在考虑如何实现它，并将尝试这样做（在这种情况下，操纵表单本身将非常困难，相反，我可以在签出过程中添加额外的步骤）。

@Ramsesx嗨，那就是：

啊，这是有道理的。谢谢你的澄清。结算协议是方便的，但我愿意以牺牲它不问我的成员自己的真实姓名和地址信息。所以我想我会做一个插件。