Double trouble

Have been running Grav without a hitch for several months. Today I accidentally added an md file with tage [first][second] instead of [first,second]
The parser crashed on this, obviously. I’ve fixed the file and still the parser crashes even though the offending characters aren’t there anymore.
I have cleared the cache, but still I get a parse error for text which isn’t there anymore.

In order to do a more thorough reset I tried to upgrade the system from my 0.9.8beta (afaik) to current (0.9.19).

Sadly I get
[Whoops\Exception\ErrorException]
Use of undefined constant CURLOPT_REFERER - assumed ‘CURLOPT_REFERER’

Haven’t a clue what that means.

Any suggestions?

Ok let’s tackle these one at a time.

  1. If you have changed the .md file the cache should rebuild automatically. However a manual clear doesn’t hurt. How did you clear the cache? with the bin/grav clear CLI command? Are you sure you changed all references that caused the parser error? Could you also paste the exact parser error?

  2. Where do you get this CURL error? During the bin/gpm self-upgrade call? It looks like you don’t have CURL itself, or the php5-curl library (debian/ubuntu etc).

(1)

Earlier I did bin/grav clear-cache, now I did bin/grav clear with the same result. I’ve grepped for the offending text and can only find it in my sync archive and the log files, i.e. in no source or cache file.

(2)

I have curl 7.26.0 (x86_64-pc-linux-gnu) libcurl/7.26.0 OpenSSL/1.0.1e zlib/1.2.7 libidn/1.25 libssh2/1.4.2 librtmp/2.3

The entire error is:

# bin/gpm self-upgrade

                                                                         
  [Whoops\Exception\ErrorException]                                      
  Use of undefined constant CURLOPT_REFERER - assumed 'CURLOPT_REFERER'  
                                                                         

self-upgrade [-f|--force] [-y|--all-yes]

Regarding CURL, you need curl support in PHP as well as the library itself. if you have a file containing:

<?php phpinfo();

You should have a CURL section:

http://polydeon.com/monosnap/phpinfo_2015-03-11_15-58-57.png

i think you probably don’t have it. What linux distro is this on?

You’re right, php-curl was lacking. Fixed that, did the upgrade without problems. There was one ownership issue, but that error message showed that grav is mostly working. After fixing that issue I’m back at my first problem:

Symfony \ Component \ Yaml \ Exception \ ParseException 
Unexpected characters near "[Openbaarheid]" at line 5 (near "tag: [AnnasHoeve][Openbaarheid] ").

That text no longer exists. It is now [AnnasHoeve, Openbaarheid], which is correct.
I also removed the entire directory, but no luck.

The stacktrace is:

18. Symfony\Component\Yaml\Exception\ParseException
…/­vendor/­symfony/­yaml/­Symfony/­Component/­Yaml/­Inline.php76
17. Symfony\Component\Yaml\Inline parse
…/­vendor/­symfony/­yaml/­Symfony/­Component/­Yaml/­Parser.php468
16. Symfony\Component\Yaml\Parser parseValue
…/­vendor/­symfony/­yaml/­Symfony/­Component/­Yaml/­Parser.php223
15. Symfony\Component\Yaml\Parser parse
…/­vendor/­symfony/­yaml/­Symfony/­Component/­Yaml/­Parser.php215 
14. Symfony\Component\Yaml\Parser parse
…/­vendor/­symfony/­yaml/­Symfony/­Component/­Yaml/­Yaml.php67
13. Symfony\Component\Yaml\Yaml parse
…/­vendor/­rockettheme/­toolbox/­File/­src/­MarkdownFile.php139
12. RocketTheme\Toolbox\File\MarkdownFile decode
…/­vendor/­rockettheme/­toolbox/­File/­src/­File.php276
11. RocketTheme\Toolbox\File\File content
…/­vendor/­rockettheme/­toolbox/­File/­src/­MarkdownFile.php53
10. RocketTheme\Toolbox\File\MarkdownFile markdown
…/­system/­src/­Grav/­Common/­Page/­Page.php212
9. Grav\Common\Page\Page header
…/­system/­src/­Grav/­Common/­Page/­Page.php116
8. Grav\Common\Page\Page init
…/­system/­src/­Grav/­Common/­Page/­Pages.php542
7. Grav\Common\Page\Pages recurse
…/­system/­src/­Grav/­Common/­Page/­Pages.php556
6. Grav\Common\Page\Pages recurse
…/­system/­src/­Grav/­Common/­Page/­Pages.php556
5. Grav\Common\Page\Pages recurse
…/­system/­src/­Grav/­Common/­Page/­Pages.php556
4. Grav\Common\Page\Pages recurse
…/­system/­src/­Grav/­Common/­Page/­Pages.php556
3. Grav\Common\Page\Pages recurse
…/­system/­src/­Grav/­Common/­Page/­Pages.php463
2. Grav\Common\Page\Pages buildPages
…/­system/­src/­Grav/­Common/­Page/­Pages.php100
1. Grav\Common\Page\Pages init
…/­system/­src/­Grav/­Common/­Grav.php219
0. Grav\Common\Grav process
…/­index.php31

would it be possible to zip up the Grav site at this point and drop it on dropbox/onedrive/googledrive etc so i can see on my local?

OK. Found it: I’m using BittorrentSync to sync the working copy on my desktop to my site, which works great generally.

Whenever I change a file, BTSync will archive the old version to a directory ...user/pages/.sync/Archive/XXX/ where XXX is the main page directory.

For some reason Grav parses these files under .sync even though they aren’t referenced or requested. Since the old version contained unparsable text the parser dies and no page is presented whatsoever.

Is there a way to tell Grav to ignore subdirectories such as .sync?

Grav looks for every file in the user/pages/ folder and tries to process it. The better thing to do is to move the .sync folder outside of user/pages/

That would make sense, though I understand why BTSync needs to archive files close to where they originate. I will see if this can be configured in BTSync. Otherwise I just have to remember to drop archives if I had a parse error

You know you should sync the whole user folder rather than just pages. That way the sync folder will be at the user level too. Benefits aw you will sync plugins and config too.

Also performance will be better because Grav won’t have navigate all the sync folders looking for markdown files.