RW7’s new web view does not have disabled cross origin restrictions. This means that I cannot make AJAX requests from within RapidWeaver. This is a really big deal and completely breaks Total CMS from working inside RapidWeaver. It would be great if you could disable cross-origin restrictions. You can do this in Safari via the Develop menu. That obviously does not help with RapidWeaver.
Thanks, got it down for Tom to take a look at this week…
i think it has to do with the WKWebView
maybe this helps?
I’ve read that that for most uses the first line is all you need. But that you can specify exact details if you need to.
Access-Control-Allow-Headers : Accept, Origin, Content-Type
Access-Control-Allow-Methods : GET, POST, PUT, DELETE, OPTION
We’re also looking at the local PHP server to see if that can help us here…
I hope that this gets fixed before any public betas.
@joeworkman A copy of something that shows this issue would be useful. We’ve got the PHP server going in internal builds, so something I can test with would be appreciated.
Go to the Admin page in my Total CMS demo project and you will see the console light up like its Xmas with errors.
OK. Is there anything more simple that we could use to preview? That project is causing WebKit to cause preview to fail right now…
We’ll take a look at why that is happening, but got something basic that we can use to verify things are fixed in terms of the CORS?
Can’t get much simpler than this… https://infinit.io/_/3Gp5EGf
(Need Foundation installed)
I should add that Foundation has a built in duplicate page checker. It looks for both
index.php. This uses AJAX and causes CORS errors inside RW7.
Thanks: in future, could you please file bug reports via email with all the details? Saves us time with the back & forth!
not sure if this is solved yet or not, but i just came across this in the docs. the call to load a URL in the WKWebKit docs comes with a second parameter for granting read access.
the docs say, “If readAccessURL references a single file, only that file may be loaded by WebKit. If readAccessURL references a directory, files inside that file may be loaded by WebKit.”
to me this sounds like it’s designed for exactly the sort of thing that we’re aiming for: granting access to a whole file-system folder. so send the fileURL of the exported preview page’s parent folder for this second parameter. seems like it’s a simple thing – worth a try. or maybe you guys already did this?
A question to the RW7 preview mode regarding PHP: already in RW6 it was possible to use some PHP functions. What about the new “local server” you referring to, and how this differentiate to RW6. Thanks!
PHP in RW6 was not guaranteed to be reliable in every case (we relied on Safari behind the scenes to provide a fair, but not complete, coverage of PHP functions). When previewing in RW7, we have a full PHP server running in the BG so basically every PHP function should work (including the contact form).
php.ini config file be edited?
With an improved PHP preview, I guess there will be some need for customization.
This is a little ambiguous. Either there IS a need for customisation or there isn’t This is what we’re using: PHP: Built-in web server - Manual doesn’t appear to support configuration of the php.ini file I’m afraid. If you have tested RW7, and found there to be a deficiency that you’d like us to fix, please file a report so we can take a look (email Dan and I!).
Sorry for my bad English. I mean that sometimes some adjustments to PHP config are needed. A way to edit
php.ini would be useful in those cases.
Of course you can specify a custom config with
-c php.ini parameter.
PHP custom config field in RW project settings would be great.
This is a fair amount of work for us to implement (as I presume you’d want it to filter down to the plugin level?) and a power-user feature really. A solid example of why this would be useful [i.e. if you’ve got specific setup issues to ensure your plugin works] would be appreciated so we can see whether we can fit this in at some point.
Not really, as you can’t do it on your online server. So a website-wide config would be enough.
Examples come from our support.
Customers have problems with not correctly configured session paths or SMTP settings, small memory size, blocked functions or wrong write permissions.
Small problems that can be fixed most of the times with a change in
If you will provide a more reliable preview that fully supports PHP, I think that this functionality would be useful.
Just my POV.