Foundation-emails: Would you be open to me submitting a PR to add litmus uploading/tests and Build ziping to this cli tool?

[iDVB]

Would you be open to me submitting a PR to add litmus uploading/tests and Build ziping to this cli tool?

With your new email workflow cli, it's all but rendering my rwdemail tool useless.
I would love the change to PR in Litmus support and Build Zipping as optional pieces in the cli.

Before I put the time in to develop... is this something you would be open too?

[rafibomb]

That's hot build you set up! We will accept a PR on this!

We use Litmus here and think most others do as well. Zipping the assets (compressed images) would help people using CM and Mailchimp, possibly others. The S3 images would be a useful option as well.

[iDVB]

Working on this now. Having a bit of a hard time understanding the ecosystem of the various repos and branches. Maybe you can help point me in the right direction.

Not sure of the difference between these...

https://github.com/zurb/foundation-emails
https://github.com/zurb/foundation-emails-template

... I can't seem to find where foundation-emails is used. It seems the foundation-cli uses only the foundation-emails-template.

So I'm thinking I need to PR the master branch of foundation-emails-template, is that correct? My PR should give template users the features of...

npm run litmus = Submit email to Litmus (after build and asset hosting on S3)
and
npm run send = Send a test email to yourself (after build and asset hosting on S3)

...I assume you will eventually want to later add some support for these from within the cli as well?

[acezard]

iDVB are you also going to include a gulp task for compressing dist in a zip file ? very useful for emailonacid or campaign monitor users. I'm also very interested in this feature because it always has been a staple in my workflow, I'm willing to make myself a PR for it asap if you wish (indeed in the foundation-emails-template repo)

[iDVB]

Yes, the plan is to have it do this as well as part of the npm run build --production build steps.

I already have the S3 and Litmus tasking integrated. Just trying to lock down how best to input the required creds. AWS and Litmus each have different recommended ways but just getting the user to input them into a *.config.json file seems the easiest, even if it isn't the best practise. Wish there was a way to add that example file to the repo and then .gitignore it for any future commits. Just so people don't accidentally PR in their creds.

[kball]

Hi @iDVB,

Sorry that the ecosystem is a little unclear. We've been having discussions about how to make it clearer and easier to use, though at least a fair amount of that is likely to be documentation. Lets see if I can clear it up:

foundation-emails is essentially just scss and testing. It is the core of the framework, but over time I see people using it more as essentially a 'runtime' requirement.

inky contains the inky parser, which parses from inky into foundation for emails compatible markup. It includes a dependency on foundation for emails.

foundation-emails-template contains the entire ZURB build stack, with gulp, inky, and a variety of other things being included in the development dependencies, and foundation-emails being the only production dependency (as it is the "runtime").

foundation-cli then creates a "project" which is based on foundation-emails-template, and the cli will just defer to the template with regards to build steps, etc.

@gakimball or @tdhartwick anything I missed?

@iDVB Does that make sense and help?

Regards,
Kevin

[iDVB]

Makes complete sense. Thanks for the clarification. I'm making good progress here. Would love to chat a bit about the PR after I submit it. There a a few things I think could/should open larger questions but I've just falled in line with your existing code.

For one, I think things are generally setup right now to process a single email. Setting things up so that you can have any number of emails (leveraging the same partials) to build and test would likely be best. Easy solve, but many workflow options.

[gakimball]

@iDVB Does having multiple files in the src/pages/ folder not solve for this, or is there a more specific workflow you're thinking of?

[iDVB]

Sorry, I meant, the code I'm implementing. There are some considerations with how things are processed when it comes to images vs pages.

Right now foundation-emails-template does not require separation of images into page associated folders, so when we go to zip them up into packages, there is no inherit way to tell which images are for which email.

Ideally, this could be done as part of a per-page pipe that only groups the images as part of the build/zip step, but looking at the existing code, it seems that may require a bit more of an overhaul.

[iDVB]

Ok, I have Litmus and S3 working with the assumption of a single email.
Having more then one email will require some thought around how to handle piping things.

Proposed dist folder after build...

Next Steps:

• Add support for sending Litmus multiple emails as separate tests
• Add support for Zipping up files
• Remove reliance on emails.config.json for Litmus test names, and S3 folder names. (instead use html page names)
• Add friendly errors for when devs forget to add all their litmus and S3 creds.

Thoughts?

[kball]

This is looking good! Some thoughts:

1. We'll need to describe what needs to be in the config file, which will at least be S3 creds
2. You may want to allow more custom headers via the config file
3. Should the build process handle setting the correct paths referencing the images in the email? IE the email developer would reference local images and the build would change that to s3? Or is it expected that the developer have the references point to s3 already?

[iDVB]

OOPS! - Sorry, when I pointed to my fork, I hadn't yet pushed. I have now.

1) We'll need to describe what needs to be in the config file, which will at least be S3 creds

Agreed, I put in a dummy emails.config.json that calls out the pieces needed. However, the final step needed here is to update the README.md and site docs.

2) You may want to allow more custom headers via the config file

Agreed, plenty of features can be exposed. Ideally, I think this config file should be organized to look like a standard Gulp one and encompass all the gulp configs for naming, paths etc

3) Should the build process handle setting the correct paths referencing the images in the email? IE the email developer would reference local images and the build would change that to s3? Or is it expected that the developer have the references point to s3 already?

Yes, npm run litmus handles the correct paths for you (local vs S3). Right now it does not handle grouping images per email. It can be debated if that is even needed for S3 though; likely not.

However, for Zipping, it will be needed, as most email vendors require the zip packages organized per email ...

[rickysullivan]

As part of my workflow I'm using my own plugin: https://www.npmjs.com/package/gulp-delete-unused-images to remove unused image assets before zipping my archives.

[iDVB]

Just sent a PR for these, works awesome.
Let me know if I sent the PR to the wrong branch or incorrectly.

[joefraley]

since this issue is still open i guess it's the best place for this comment. @iDVB seems to be working on this

I'd love this to work. In my workflow I'm seeing gulp crash at this point.

Two console logs here to see where the crash occurs. See the first one succeed in the output above.

Never reach the second log, so the crash occurs in the gulp.src or $.htmlSrc functions?

UPDATE: the problem seems to be how the pathing works in src/pages/*.html files.

notice that the path to the image assets FROM the src html SHOULD require crawling up one directory first. The intuitive relative path works for npm run build and npm start but not npm run zip

[iDVB]

@joefraley I think it would be better if we left this thread/issue closed and you submitted your issue as a separate issue. Feel free to reference the specific commit or release that you suspect is the culprit.