Hello Alex,
In terms of the cache time, be sure the config file you’re setting this in is active, i.e., make sure that if you’re in production that it’s placed under the production settings.
As you mentioned, you’ll need to restart Puma after making any changes to the config files and, possibly, to the example_data.rb file as well. There shouldn’t be a need to restart the other processes.
When static files are enabled , the JSON is pulled from
config/initializers/landing_page.rbwhen the Custom Landing Page (CLP) Editor is not being used; it pulls fromapp/services/custom_landing_page/example_data.rbwhen the CLP Editor is activated. If you’re editing these settings while the static mode is enabled, you’re likely to encounter some caching issues which I’ll address under Settings.
Be sure to check if the CLP setting is enabled. Looking back, I can see that I wasn’t very clear about this, which is a shame because now I’m not very certain either. I think I’m refering to a boolean value in the DB, which I set in app/services/plan_service/data_types.rb. The simplest way to check this would be to make an edit in config/initializers/landing_page.rb and see if this is reflected on the site after clearing the cache and restarting Puma. I suspect this will work for you, allowing you to switch the CLP option off to continue using the example_data.rb file or to copy your JSON into the file currently being read.
While you’re likely set to use the static option (unless the config isn’t being read), it may be worth checking and editing the DB’s landing_page_versions table. You can try modifying this to see if it updates, clearing cache and restarting Puma. If this works, it’s being read from the DB which probably means the clp_static_enabled is set to false.
I’m not sure what clp_static_released_version is doing if static is reading from a Ruby file. To me, this implies it’s using the DB (in which rows define the current JSON in use by version). It’s possible that reverting this option to 1 would result in it using one of these default Ruby files like you expect.
I don’t claim to know how the caching works for Sharetribe, but I’ve also wiped the .cache folder when in doubt. Consider this a last resort, perhaps something to be repeated after modifying config/initializers/landing_page.rb, app/services/custom_landing_page/example_data.rb, and the database’s JSON version #2 (of whatever’s set to be in use). If all of the above steps didn’t identify which file is being rendered, then make each of these different files show something different enough to be identifiable: Copyright 2020, 2021, 2022, for example. Then do a hard wipe of the cache.
Be safe about it, I don’t know your particular build or what was going on in that version, so I’d reccomend a quick recursive copy first (mkdir ../oldCache && cp -R .cache ../oldCache from the directory which contains .cache. Then, wipe it all out: rm -Rf .cache. Restart Puma and get a cup of tea: it’ll be a much longer build. For complete confidence that the RAM is clear as well, do a reboot before restarting Puma. (The reboot should be completely unnecessary and doesn’t even make sense, but I find myself becoming superstitious when I’ve been banging my head on the wall long enough.)
Best of luck! Let me know how it goes and perhaps I’ll edit my post to clarify this. I do believe the three sources identified are the only CLP files available to Sharetribe, though if this does not fix it I’d do a grep to find other JSON and parse it by hand to see what else it could be pulling the page from.