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
-
Change
config/config.defaults.yml:clp_static_enabled = falsesets dynamic mode,show_landing_page_admin: truewill show the CLP editor in the admin menu -
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] )
-
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) -
Restart Puma using Foreman. Make sure the prior process is killed, then run something like:
foreman start -f Procfile.static -
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.
