Call to undefined method HashOver\Setup::getImagePath()

[linuxitux]

The latest commit 7a38fd119dd27b50511d007e3ae2235ab6706a26 gave me this:

2018/03/02 07:09:40 [error] 2442#0: *3895 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined method HashOver\Setup::getImagePath() in xxxx/hashover/backend/classes/hashover.php:222
Stack trace:
#0 xxxx/hashover/backend/comments-ajax.php(36): HashOver->parsePrimary()
#1 {main}
  thrown in xxxx/hashover/backend/classes/hashover.php on line 222" while reading response header from upstream, client: x.x.x.x, server: xxxx, request: "POST /hashover/backend/comments-ajax.php HTTP/1.1", upstream: "fastcgi://unix:/xxx/php7-fpm.sock:", host: "xxxx", referrer: "https://xxxx"

Of course nothing is displayed.

[linuxitux]

My bad, I was using an older settings.php

I think you need to keep the configuration isolated from code, and centralized in one place. That way it would be easy to upgrade to a new release.

Thanks.

[linuxitux]

Seriously, it's annoying to have to manually edit settings.php in every new commit.

[CyberShadow]

Practically all web apps will always have a separate, non-versioned file where configuration is stored. For example:

• MediaWiki has a LocalSettings.php, which is intended to be created and edited by the user.
• Mantis has config_defaults_inc.php (contains defaults, not editable) plus config/config_inc.php (to be created/edited by user).
• Wordpress has wp-config-sample.php and wp-config.php with the same idea.
• Owncloud has config.sample.php and config.php
• etc.

So, yes, hashover should not expect users to edit files that are in version control / included with the distribution. It's not just annoying, but dangerous (a skipped step in the upgrade process can result in losing the previous configuration).

[jorgesumle]

Remember that this version of Hashover is not ready for release, it's a development version. I guess you can make a GNU sed script or something similar to set the configuration to your preferred values after an upgrade, if you do that you should make sure the upgrade doesn't require any modification of your script.

[CyberShadow]

Remember that this version of Hashover is not ready for release, it's a development version.

Of course. That doesn't get in the way of helping make a list of things to improve, and discuss the best way to improve them.

I guess you can make a GNU sed script or something similar to set the configuration to your preferred values after an upgrade,

Currently, a much simpler method is to use a git checkout. Before upgrade, git stash your changes; git pull to upgrade; git stash pop to restore your configuration. This has the benefits of 1. it's harder to accidentally overwrite your changes, a git reset or checkout is needed 2. when an option is renamed, the last step will fail noisily (and must be resolved as a git merge conflict), so you are forced to review situations that might otherwise result in a misconfigured instance.

[CyberShadow]

Fix: #213

[linuxitux]

@jorgesumle I know it isn't ready for production, but this issue makes helping in the debugging process and contributing a very tedious task.