Our CSS gets LFTP’ed over to Coded Files and does not suffer the same issue.
The Errors
When visiting the URL of the file on hubspots CDN - we get a 403 forbidden error. If we upload the file directly via FTP or the GUI - we do not get the same issue.
@dillonbailey thanks for your quick response. I saw your comment about that above and it didn't occur to me to try that! I'm testing this now.
One caveat is that we are hoping to share css & js between our HubSpot instance and non-HubSpot pages within the same design system. This makes inserting {% %} tags dicey. I've been testing this morning with the raw tags, with raw tags wrapped in comments, other various scenarios. My results are basically as inconsistent with the raw tags as they were without. Sometimes the upload goes fine, sometimes I end up with the file's content replaced with HubSpot's default HTML.
For what it's worth, my javascript file literally consists of this:
function psyche(){
/* this is a test js file */
fakeSomeStuff();
}
Literally just some test code in there, nothing to be misinterpreted by the validator. @dillonbailey has using lftp been working for you over the last three months?
@Derek_Gervais is there anything you guys have discovered on the HubSpot side between November & Now?
Hey mate, that’s frustrating! But good thinking keeping it simple for testing, we went through the same experience. We have not run any deployments since December 2017. Also that was pre web designer beta..
I would offer two options, if you’re super keen on hubspot hosting the files, try some different file locations in their folder structure.
The better option in my opinion, if you’re using this same code on non hubspot pages, move your CI/CD process to just deploy your css and JS to AWS S3. No weird file processing issues and easy enough to put behind cloud front for a CDN. Will offer a better and more consistent experience. Codeship has a 1 click integration for this sort of deployment that makes it even easier.
I am seeing similar issues when trying to FTP files from gitlab using lftp. If the file is new (and contains properly formatted content for it's file type, to get past the validator) it gets uploaded file. I've opened the files from the server through Transmit (FTP) and verified that they contained the code from gitlab as expected.
However, on subsequent commits, which trigger gitlab CI to mirror the files to the server, I am seeing the following error:
"mirror: Access failed: 551 /portals/xxxxxx-domainname/content/templates/custom/page/css/test.css: Error on output file."
The contents of test.css get replaced with HubSpot default html:
It could be a race conditions thing, as mentioned. Not sure... but would definitely like to know if there is a way around this issue, as we are trying to verify if this is a process we can rely on in our workflow.
Hey @jvanpelt - o.k. so what I think is happening here, is that your file contains something that the processes at Hubspot are thinking is HuBL...
What I would recommend is ensuring that your file has {% raw %} file contents here {% endraw %} tags. We added ours to JS via gulp as part of the build process.
Essentially this is using an LFTP mirror command from codeship. I’ll send you the exact command when I’m next online. But from what I can gather if a file exists with the same name it will just run a replace on that file, so perhaps the delete, upload of replaced files is the race condition?
@Derek_Gervais here’s the LFTP command, this is placing the contents of images into the directory on hubspot. $FTP_USER and $FTP_PASSWORD are env. variables that you can plain type in your local CLI for testing.
So after digging into this, it looks like the file references for those two images were coming up as deleted. Can you give me some more information on how you’re uploading these files? My current theory is that there’s a race condition between a file upload and a file delete, which is causing some weirdness.
Hi @Derek_Gervais unfortunately it looks like our problem is back, this time with some more standard file types, JPG and GIF files deployed to File Manager via LFTP are producing the 403 forbidden error.
You can see in this screenshot some other images that were deployed as part of the same task that are working A-OK.
Hi @Derek_Gervais still shows a 403 if we upload via Codeship - to keep on development we’ve just had to upload via standard FTP with filezilla which removes the error but is manual.
If it’s helpful I can upload a test.js file for you via lftp from codeship for testing on your end?