Stuart Silvester

We haven't had to enforce it yet, we're still human and realize there's a lot of things that have changed for 4.5. We just want to make sure that we're not constantly rejecting things for the same reasons.

To be fair, this was detailed in May, CSRF protection works exactly as it does on the front-end, there are not any functional changes to how you implement it.

Yes, the 'onboarding' page may not work reliably for everyone in Beta 9, but it should in Beta 10.

In 4.5 we added the ability for the AdminCP menu 'bubbles' to show if you have any resources that need updates, this shows globally on every page of the AdminCP. The respective applications/themes/plugins/languages listing pages (in the software, not the Marketplace) show if the Marketplace resources have updates available. If you're not seeing update available notices and you know that you should be, please submit a ticket so I can have a look at the issue.

You need to use either the account that your license is assigned to, or an account that has been added as an alternate with full access to your license.

Yes, this was fixed in beta 9. The admin defined preference is now always used if the end-user hasn't specified their own preference.

Facebook are still investigating the issue and they may have reverted the change that caused the issue. Facebook deprecated the cover field in v3.0 of their Graph API (which you are likely using unless you have manually switched your FB app to a newer version, or created the app recently). The issue seems to be that they unintentionally started to return an error for this field - https://developers.facebook.com/support/bugs/297556258061769/

Your issue isn't related to what this topic is about, the issue in this topic is a permissions related issue due to a change in the Facebook API where they no longer allow you to obtain cover photos. I would recommend making sure you have the above patch installed, then follow this guide: step 7 includes a screenshot showing the configuration for the form where the redirect URI is entered. If you're still experiencing an issue, please submit a support ticket so we can look into it.

We have released a patch for this issue, you can get it in your admin CP by going to Support and selecting "something isn't working"

We're aware of the issue, we're working on a solution.

You only really need the 'COOKIE_PREFIX' constant to prevent conflicts, you will probably need a trailing slash on the cookie_path however, so /test1/

I would recommend submitting a support ticket, the converter automatically handles the difference in IDs but I can see in the converter that we're expecting 'tid' for showthread.php, not 'pid'. Submit a support ticket, we can test the addition of that rule for posts.

We'll look at the possibility of making the onboarding process load again in the next beta. We've made a few fixes in this area so you should be able to find them in the next beta.

Please submit a ticket if it's still an issue.

The update will show in the AdminCP the next time an update check runs, you can do this manually by going to AdminCP > System > Applications > Check for updates.

That doesn't sound right, there should be an upgrade button if there is an upgrade available. If your AdminCP is still in that state where the issue is visible, please submit a ticket.

Please re-download Beta 8 (and upload to your community) from the client area, we pushed out a patch about an hour after the initial release of Beta 8. Alternatively, you can wait until the next beta which will apply this fix to your community.

Hi @cdymlr The best way to do this is to use mod_rewrite in the .htaccess file for your root domain to redirect the specific MyBB requests. Looking at their existing rules that ship with MyBB, you can simply just change them to have your complete URL in them i.e. RewriteRule ^thread-([0-9]+)\.html$ https://forums.root.com/showthread.php?tid=$1 [L,QSA] However, if you weren't using MyBB friendly URLs, you would need to customize the rules to redirect the PHP controllers instead... RewriteRule ^showthread.php$ https://forums.root.com/showthread.php [L,QSA] (you would also need to do this for the other supported URLs such as member.php & forumdisplay.php) You will likely need to tweak and test these to meet your specific scenario, but that should give you an idea of how to address the issue.

There may be a bug here, we'll take a look at this.

Yes, the new endpoint will generate a signed URL for the files if the Storage handler supports them.

4.5 contains a bunch of improvements in this area to make plugins more portable. They can be installed IN_DEV and the majority of their data is now stored within the /dev directory in various PHP/JSON/PHTML files. We haven't made any changes to the naming conventions required, or the hook class names, but we've also come up with these changes for the same reasons, to greatly improve the ability to develop plugins across installs via Git. Please consider taking a look at the beta and letting us know whether those improvements are beneficial to your development process.

This issue will be addressed in our next beta.

It looks like Account Kit was discontinued and is closing completely this month. https://developers.facebook.com/blog/post/2019/09/09/account-kit-services-no-longer-available-starting-march/

You can enable Twitter cards by going to AdminCP > System > Settings> General Configuration and enter your sites Twitter handle in the box

You must add and validate the email address in SendGrid that you're sending from: https://sendgrid.com/docs/for-developers/sending-email/sender-identity/ Make sure that the outgoing address on AdminCP > System > Email Settings is exactly the same as the validated address (or on the same domain if you have validated the domain).