Hey! Sent an email to their support to understand how the filesystem works, here is the reply:
It looks like the default install for GS would be kind of strange. I'm going to setup a Github repo for it, and start fiddling until I can do a clean install on pagodabox. Then people can just fork it if they want to install on it.
I for one think it would be rad to have an install option on their app cafe, so folks could easily use pagodabox for GS installs.
Anyways, I wasn't able to finish the above email, but here is what I can ascertain:
Whatever "single file" items we have that are not writeable, we need to create two copies of and then create hooks.
Do you have a github repo setup for what you are using? If you do I will fork, install and try out a couple things. I think there a couple single files in /admin that need to be writeable.
Thoughts?
Quote:> 1) .htaccess setup will not work?
Could you clarify a little more on how it will not work. If the cms is trying to edit the .htaccess in the runtime environment, it won’t work. Pagoda Box is a read-only environment (discussed mroe below). If you’re making changes to the .htaccess locally, then pushing those changes up to Pagoda Box, it may be a simple syntax error in the .htaccess.
> 2) Boxfile shared writeable is not Recursive?
Whenever you specify a directory as a shared writable directory, those permissions are recursive. You can modify that directory in any way you’d like. Be sure that in the Boxfile, it’s spelled “shared_writable_dirs” and not “shared_writeable_dirs” (no “e” in writable).
> 1) Is there a way to make shared writeable individual files?
There is a way to make a single file writable. It involves storing two versions of the file in your repo – one in it’s normal location and the other in a shared writable directory. You then use an after_build hook to symlink the two files.
Note, the Pagoda Box infrastructure is very different than traditional hosting. Apps consist of multiple instance that are spread across multiple servers. If each of these instance were able to write to their filesystems, they would write themselves out of sync, leading to some odd behavior for your app. Shared writeable directories are a centralized writable filesytem that is shared between all app instance. There are some caveats when using network filestorage. Really, shared writable directories are only meant for static assets like images and user uploads. We highly discourage ever storing any code in a shared writable directory for reasons below:
No Version Control or Emergency Rollbacks – Writable storage is not tracked by Git, so if any bugs are introduced through writable storage, there is no easy way to roll back to a previous, bug free version. You’ll have to manually edit the code.
Decreased Performance – Writable storage is housed on a storage cluster separate from your app’s components. While minimal, network latency does increase response times to files stored in writable storage. Running source code in your writable storage negates the performance optimizations built into the Pagoda Box infrastructure.
Code Caching + Writable Source Code = No Bueno – Opcode cachers like APC and eAccelerator are great for improving the performance of your app. But they do cause problems when multiple web or worker instances are running source code from shared writable directories. When code is cached on Pagoda Box, we assume the code is read-only (which it should be). Once a code cacher caches the file, it never reads it again. So, when an instance caches code, it’s cached until you redeploy. This can lead to odd behavior like code updates not being reflected in the live app or instances in the same app serving up different versions of the code.
Network File System Reliability – Shared writable directories are network file stores. If the network connection is interrupted in any way, source code stored in a shared writable directory will be temporarily inaccessible, potentially causing an error in your application. In some cases, these errors can only be fixed by restarting your web process or redeploying your app. Anything to which your app must have a constant connection should not be stored in writable storage. Pagoda Box takes every precaution to make sure network connections are always stable, but interruptions can happen.
It looks like the default install for GS would be kind of strange. I'm going to setup a Github repo for it, and start fiddling until I can do a clean install on pagodabox. Then people can just fork it if they want to install on it.
I for one think it would be rad to have an install option on their app cafe, so folks could easily use pagodabox for GS installs.
Anyways, I wasn't able to finish the above email, but here is what I can ascertain:
Whatever "single file" items we have that are not writeable, we need to create two copies of and then create hooks.
Do you have a github repo setup for what you are using? If you do I will fork, install and try out a couple things. I think there a couple single files in /admin that need to be writeable.
Thoughts?