Paul Fernhout

@metachron Thanks for trying NarraFirma and for taking the time to report an issue. Sorry for not responding sooner. We’re new to this support forum and did not notice your post until now; we assumed, incorrectly, we’d get emails on new issues, but that does not seem to be the case. Now we have now set up an RSS feed reader to check for such issues.

I copied the PHP code from both GitHub and www.ads-software.com (SVN) through a PHP Code Checker (phpcodechecker.com) for version 0.9.4, and the code checker does not indicate any sort of issue it could find with narrafirma.php. I checked the latest version at GitHub and it seems OK too. Typically that error happens in PHP when something is wrong with the syntax of the file, like a single quote is misplaced, or when there is an extra character at the beginning of the file, or something like that. However, we are running the code in production (including loaded from www.ads-software.com) and know of others who are doing the same, so it seems like the code starts up for at least some people. Unless the issue is due to hand-editing or something like that which might accidentally add a character to the start of a file (but unlikely on two separate installs), perhaps there is some non-obvious issue with character encoding related to whatever platform you are using or related to how we checked the code into SVN at www.ads-software.com? Any additional details you can tell us about the platform you are using or how you installed the plugin could help us track this down.

You could also try downloading the 0.9.4 release or earlier releases (as you asked about) directly from GitHub at the following link and see if that fixes the issue, which would help determine if it was an SVN-specific issue at www.ads-software.com:
https://github.com/pdfernhout/narrafirma/releases

We’d like to help you get this working, so please let us know how it is going. Feel free to email either Cynthia or me for more direct assistance on getting you going with this.

You could add debugging code (in a test environment, using error_log) to log what all the options are and then look at the results. You ideally do not want to do this in a production environment as such debugging code would slow your system further. Alternatively, and maybe easier, you could use an interactive SQL tool (very carefully) to look at your production database to see what is being stored in the options data. If you’re not comfortable doing any of that yourself, you might want to hire an experienced WordPress consultant to do it for you.

That might help in determining whether some plugin (or core code) is abusing the options system to store more data there than it should. A plugin might be, say, setting a unique option for every product or post or something like that, where a lot of data should otherwise be stored elsewhere to avoid exactly this sort of issue. If that is the case, then you could file a bug report on the specific plugin or core system.

Of course, the issue could be from a totally different cause. This is just a general suggestion as a first thing to try for troubleshooting this.