Landing Pages for Idiots Like Me

I have spent an inordinate amount of time enabling and setting up the landing pages on a VPS installation of ST. I’m going to share my experience, hopefully sparing the next fool to wander where angels fear to tread.

First, we have two implementations of the Custom Landing Pages module: Static and Dynamic. Both rely on JSON, the former retrieving JSON from a file that will be edited by hand and the latter relying on your database and the WYSIWYG-ish Landing Page Editor.

I’m personally using the dynamic option to save time with simple development and then copying the code into a static build which I’ll implement once I’m ready to switch to production. The code generated by the dynamic option is, appropriately, stored in the database under landing_page_versions.

When static files are enabled, the JSON is pulled from config/initializers/landing_page.rb when the Custom Landing Page (CLP) Editor is not being used; it pulls from app/services/custom_landing_page/example_data.rb when 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.

I’ll be activating the CLP Editor and staying in Dynamic mode until its ready for production or advanced (i.e., custom) features. Since Dynamic mode makes an additional call to the SQL DB and retrieves a modestly large bit of JSON, there’s likely a performance improvement to using Static in production. I’m going to document this process as I wish it had gone for me.

Activating CLP and the CLP Editor

  1. Change config/config.defaults.yml: clp_static_enabled = false sets dynamic mode, show_landing_page_admin: true will show the CLP editor in the admin menu

  2. Change app/services/plan_service/data_types.rb: Change the defaults beginning in line 3

module PlanService::DataTypes Features = EntityUtils.define_builder( [:deletable, :bool, default: false], [:admin_email, :bool, default: true], [:whitelabel, :bool, default: true], [:footer, :bool, default: true], [:landing_page, :bool, default: true] )

  1. You may need to initialize the CLP components of the DB:
    PlanService::Store::Plan::PlanModel.create(community_id: 1, status: "active", features: {"deletable":false, "admin_email"=>true, "whitelabel"=>true, "footer"=>true, "landing_page":true}, expires_at: Time.current + 90.years)

  2. Restart Puma using Foreman. Make sure the prior process is killed, then run something like: foreman start -f Procfile.static

  3. The CLP editor should now be available in the admin UI as a listed option.

Dear friend, these directions will, with fortune, age very poorly. It does not make much sense why I had to “hack” the CLP Editor feature in the open-source version of this project, for example. I’ve read that others have the CLP Editor available by default, even, though I’m skeptical of this claim since the version I pulled two days ago has the CLP defaulting to false.

With any luck, you can now edit your CLP in the backend and have it display correctly. If not, read on.

Getting Dummy Text/Default Landing Page / Not Updating
If you’re in Static mode, you’ll continue to see either of the .rb files I mentioned earlier, not the dynamically modified files created during your CLP Editor workflow. Disable Static mode.

I’m editing in Static mode. Nothing’s changing.
The cache defaults to 15 minutes. You can change this in config/config.defaults.yml, but I’d advise adding a line to config/config.yml under development: clp_cache_time: 1

I want to switch from Dynamic to Static
Use Adminer to copy the JSON from the aforementioned field. Paste this JSON into config/initializers/landing_page.rb and set config/config.defaults.yml: clp_static_enabled = true. There may be a small performance from disabling the admin CLP editor by reverting the file above, but it’s likely only trivial.


You are going share suggestion or help or what ?

Thanks @jeremyevinced! A very helpful list!

I’ve linked to it in the Readme file, at

1 Like

Thank you, I’m honored to contribute in my own small way. If folks like you keep pumping my confidence, I’ll have to start making making pull requests. This is an amazing project that has benefited uncountable people, including myself and my clients.

1 Like

Hi Jeremy!

A year ago I successfully changed “copyright”: “© 2020 Copyright” line in example_data.rb on production site. In general, a year ago any changes in example_data.rb were successful.
But this year I try to change “copyright”: “© 2021 Copyright” without success.
On staging site all is OK, it works, I can change what I want.
I have the old ST Community Go 6.1 version. In config.yml on production I have:
clp_asset_url: “/landing_page/”
clp_static_enabled: true
clp_static_released_version: 2
clp_cache_time: 1
As I remember a year ago I was making changes in example_data.rb and after refreshing browser I could see changes.
Now I run sphinx (ts:index, ts:start), delayed job, puma but with no result.
Maybe changes were made in the configuration files, but I do not know what was changed.
Could you direct me on this matter?

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.rb when the Custom Landing Page (CLP) Editor is not being used; it pulls from app/services/custom_landing_page/example_data.rb when 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.

1 Like


I started from your first paragraph. My config.yml is in /root/config folder.
I solved comment this line in config.yml to check if it is active:
# clp_asset_url: "/landing_page/"
And this change works both on staging and production. I can see missing pictures. But I noticed one feature. When I use defined locale this commented case works. But when I use site address without locale I see all pictures. In short, changes in config.yml work under locale (site/en/ or site/de/) and don’t work if I use simple address (site).
It turns out that the configuration file works, but in a strange way.
Although it may be true because in example_data.rb we use three sections:
But I don’t know for sure.
I will continue to next paragraph…


I have no landing_page.rb in my folders. As I know there is no this file in the new 10 version too.
I work with ST v6.1 and this version doesn’t have CLP editor. Maybe you mean that I need create this file? Also I can check a certain field in the database and change it if needed. But I don’t know which field to check. Can you tell me how to clear the cache before run Puma?
I checked landing_page_versions table but all fields are empty on production and staging.
Jeremy, what to change in landing_page_versions table? I can do it. But I do not know which field to update and with what value.
I also replaced clp_static_released_version with 1 (there was 2). But the same. Simple changes in example_data.rb not reflects in site.
In the project root directory on production I found cache in tmp folder, not .cache:
under assets we have production and staging, under production folder we have sass and sprockets.
Some folders and their files are with current date.
I decided to follow your recommendations to cache on staging.
I removed all under cache. Then restarted Puma. After this cache’s folder tree restored as it was. Staging site works as before. Everything went well.
So I can try the same thing on production.
I repeated the same on production and now editing example_data.rb successfully reflected on the site.
It seems cache removing helped me. Your last advise in your recommendations was successful to me.
Thank you very much!