So, I’ve managed to set up a Vanilla Forum site, not using Softaculous but with a custom build. But when I go to edit settings in my administration panel, I keep getting “Network Error”. It also removes the changes I set up.
Judging by that second error message, I’m guessing that Vanilla Forums is trying to do a HTTP PATCH request? Those are not supported on our hosting I’m afraid, only the GET and POST methods are supported.
Anyways, guess I’ll find another way to get the data to update. Maybe I can do a POST request to a script that generates a new file? I’m still working out Vanilla, it’ll take me a moment.
The idea is that normal websites don’t use it. Almost all web requests only use GET (to load pages) and POST (to submit data/forms/etc.). Other HTTP methods are typically associated with REST APIs, and the idea is that they are therefore not necessary for websites.
Of course, if you then have a REST API in your website and have Javascript on your site communicating with that API, you can definitely use other HTTP methods, and still qualifies as regular website usage.
Maybe I can check if this can be adjusted.
Maybe something like that is possible. But I won’t fault you for not liking the idea of tinkering with Vanilla Forums source code.
I’ve already broke (and fixed) the forum numerous times trying to hack in a solution. There’s just one page that needs the patch but I can’t seem to figure out how to properly implement.
I’m also considering just making a plugin that “recreates” the page with the patch, in another location. But I’m still settling in. Worst case scenario, I go back to the h-ll of Flarum.
If this does get adjusted, would this also fix WordPress sites? Or does it use something else I’m not understanding?
iFastNet enabled support for the additional HTTP methods! Both the PATCH call for Vanilla Forums and the DELETE call for the Elementor submissions should now work.
The reality is that many websites nowadays rely on Javascript frontends that communicate to REST APIs on the backend. And these APIs frequently make use of other HTTP methods than GET and POST.
There have been more people running into this limitation in the past, and I remember another recent case from someone with a mystery 403 error in a backend which might also have been caused by this.
So enabling it for individual URLs doesn’t seem like a scalable solution to me, and it seems that iFastNet agrees.