Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FormSave fails on submission on staging server #8

Closed
graphiclunarkid opened this issue Apr 11, 2014 · 5 comments
Closed

FormSave fails on submission on staging server #8

graphiclunarkid opened this issue Apr 11, 2014 · 5 comments
Assignees
Labels
Milestone

Comments

@graphiclunarkid
Copy link
Member

We need to get FormSave working on the main form on the home page. Not sure what's going on there - @webal's best guess to date is that the db it's using isn't created or permissions for it set up.

@mkillock
Copy link

FormSave was working, data was going into the database. The problem is that the manager component wasn't working because it could not find the /srv/modx/revolution/config.core.php file. For some reason it looks for it in /srv/config.core.php, which I presume has something to do with ORG moving the assets folder to /srv/assets, and FormSave's assumption about the location of the config file, such as just looking up one folder level from the 'assets' folder, assuming the rest of the modx installation is in /srv. That's just a guess but possibly a bug on their part though because there are separate 'core' and 'assets' MODx configuration values which should allow users to move the assets folder elsewhere as ORG have done.

Anyway, the fix is to copy or symlink the /srv/modx/revolution/config.core.php file to /srv/config.core.php so that the FormSave manager component can configure itself correctly.

A symlink probably is better, given that the location of these files may be different in production and in staging.

If it's not working in production, then you can find out what location FormSave is trying to find config.inc.php by watching the apache error log, immediately after clicking the Manager side component.

@mkillock
Copy link

I've opened a bug report with FormSave:

b03tz/FormSave#19

@graphiclunarkid
Copy link
Member Author

I agree symlinking is better in our situation. Maintaining two copies of config.core.php sounds like a recipe for confusion!

I'm going to close this issue now because you've resolved our immediate problem (thanks!) I think we need to review this when we move from development to staging, though, and again when we move from staging to live. I'll create new issues for those tasks so we have something to work against.

@graphiclunarkid
Copy link
Member Author

I've looked into this a bit further and I think I have a fix for the upstream code. I'm going to submit a pull request there.

I realised belatedly that I should have left this issue open until the upstream bug has been closed even though we have a work-around so I'm re-opening it. We can close it once a new version of FormSave is available.

@graphiclunarkid graphiclunarkid added this to the Version 2.0 milestone Apr 13, 2014
@graphiclunarkid graphiclunarkid self-assigned this Apr 13, 2014
@graphiclunarkid
Copy link
Member Author

I guess b03tz/FormSave#19 isn't going to get merged any time soon :(

I'm closing this bug because we no longer rely on FormSave - it's just a backup mechanism now. Also, this patched version seems to be working fine, and we can continue to use it even if the bug never gets fixed upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants