ItzNotABug / ghosler

Send newsletter emails to your Ghost CMS subscribers & members, using your own email credentials!
Apache License 2.0
41 stars 5 forks source link

Doc Suggestion + Feature Suggestion #9

Closed KyTechInc closed 6 months ago

KyTechInc commented 7 months ago

Hello!

Thanks for working on a project like this! This is not an issue per say but a suggestion and question about the docs.

  1. the ReadMe references this line "Fire up the Ghosler front-end by going to https://your-domain.com. Default PORT is 2369." but there seem to be no instructions on how to start the dev or webserver and no "scripts" functions in the package.json to give a clue. So right now, not sure how to run the app.

  2. Secondly, and unrelated to #1, I'm wondering if a feature could be added to the config file to help with the sending of newsletters for people who are using Ghost in a headless fashion. Namely, adding another variable like "headlessUrl" where you state your front-end site URL which also would get injected similar to the "URL" value into the email templates. This way when users click in the email it will get routed to the correct place. Something that is majorly missing from Ghost's email settings or even config.

ItzNotABug commented 6 months ago

Hey @KyTechInc 👋,

  1. I think the Running Ghosler section on README shows installing instructions via ghosler-ci, so you only need to manage the CLI. If you intend to manually run the app, its as simple as node app.js or pm2 start app.js --name ghosler-app, or whatever process manager you are using. The entry-point is app.js.

  2. Could you provide more details on this? I am a bit aware of Ghost's capabilities to be used as a headless CMS but not really sure what you mean here - Namely, adding another variable like "headlessUrl" where you state your front-end site URL which also would get injected similar to the "URL" value into the email templates.

A clear description with an example would help.

Thanks.

KyTechInc commented 6 months ago

Hey @ItzNotABug, thanks for the reply.

  1. maybe I'm not understanding how Ghostler is working. I installed and ran the CLI locally, all that worked and I'm left with a set of folders matching the GitHub repo structure. I can see the files I need to config to my hosted Ghost API, URL, etc. But wasn't sure how to run the front end as described in order to see the web console. running node app.js just returns an error. Again, maybe I'm missing something here.

  2. Sure! So running Ghost in "CMS mode" is really just turning on the private mode setting in the ghost admin, which hides the frontend or public blog site and only allows login to the admin portal "/ghost", as well, it exposes the Content API and Admin API endpoints. For me, I use this to grab all the blog post data and render it in something like a NextJS site. All of this works, however, when you try to publish a post and send via the built-in newsletter function the email template has a pre-coded variable for any of the links in that email which it uses the public URL of the ghost site, "blog.domain.com". In a headless setup you don't want any links to reference the actual ghost front-end as either one its turned off in private mode and 2 you want it to hit your separate front-end site: domain.com/blog/$slug.

I have tried to edit the ghost email template however it sits within the core code package or node modules of the Ghost code base which means it gets overwritten with each update. I've also tried using the redirects function which kind of works but gets very messy quick. Since Ghostler is handling the sending of the newsletter outside of the ghost codebase I saw it as a way to create a workflow that is more targeted to handling a Headless setup.

Hopefully, this is more clear?

ItzNotABug commented 6 months ago

I understand your point 2 better now. While it is a good feature, unfortunately it is out of the scope for Ghosler. Adding something like headlessUrl will break a lot of things if the frontend does not manage certain things like: subscription page, unsubscribe page, feedback sheets & popups, comment links, etc.

That said, you can maintain a fork if you wish to. You'll have to replace calls to (await ProjectConfigs.ghost()).url with your frontend url after you add it in the config.production/debug.json.


Coming to your installation, Where & how exactly did you install Ghosler-CLI & Ghosler? I am assuming you have a working server with an IP address. You should have a domain mapped to that IP & all requests for Port 2369 must be proxied through.

KyTechInc commented 6 months ago

I think your right about my purpose version needing to be a fork to truly get the benefit and also not break the current core functions. I'll think about making a fork, although I've never maintained a fork before so i would need to doing some reading on how to do that and not break things lol

As for the installation, I'm starting to piece together that maybe Ghostler is meant to be installed on the same VM, node etc as your running Ghost instance and then your just routing to either base on a 1 port number difference (2368:2369).

I was trying to run this from my laptop thinking I would just run it locally and point it at my running instance of Ghost's public domain? Let me know if im off here? I also don't think i can install this alongside my ghost or on the same VM as I am using Railway.app and I don't have the same controls to the host OS as you would with something like a DigitalOcean droplet or other.

Apprentice you taking the time to review all this btw

ItzNotABug commented 6 months ago

I'll think about making a fork, although I've never maintained a fork before so i would need to doing some reading on how to do that.

I understand, it can be a bit tedious to look up at the latest changes from master repo and then make changes to your fork. Let me know if you stumble anywhere.

I was trying to run this from my laptop thinking I would just run it locally and point it at my running instance of Ghost's public domain?

No, this wouldn't work because the public internet doesn't have access to your localhost.

You could however try using tunneling via something like NGROK which helps you in exposing your localhost to internet. That way you'd have to still keep the tunnel active when publishing a post so the localhost can receive the content via webhook. But honestly this is just a rough idea, haven't tried tunneling before.

See: https://www.twilio.com/blog/expose-localhost-to-internet-with-tunnel for references.

Cheers!