Sep 10, 201811:42 AM - edited Sep 10, 201811:51 AM
Member
Template structure & relative paths
SOLVE
I'm in the process of looking into the migration of an existing website into hubspot. I have some questions;
I'm having trouble figuring out how relative paths work, which cooincides with best practice of structure in HubSpot.
Said project has a lot of javascript libs. Should these be uploaded with the File Manager, or should I create new javascript files in the templates folder using designer tools and copy / paste?
For files uploaded using File Manager, it seems that the only way to reference them is using absolute URL's.
Can files here be referenced in a relative way, so as to avoid having to change file paths in code later? I've searched - and seen suggestions to prefix with hubfs etc, but when previewing a template the domain is generic. I see no API to help with this either.
Is this the correct place to upload static assets a template might need? (Favicons, Background SVG's, external libs etc?)
Is there an existing HTML template that might help illustrate some of these questions instead?
I found SOME training online, but it's due to be removed - and seemsout of date. Are there any new training materials or courses I could run through that'd answer some of this?
If we can't use relative paths - what happens when we migrate to a new domain?
For reference, I've tried the following paths;
# Uploaded to: /public/site.css # In HTML, attempted to ref like;
# previewing a template uses a generic domain, so I didn't expect these to work. /hubfs/public/site.css /public/site.css
# copying the public url via file manager, and then removing the domain. /hubfs/1234567/public/site.css
Any help re: best practice and how to structure my HTML in regards to external references etc would be most helpful!
You sound like you have some development chops. It can be wierd transition from the wastelands to an oasis, but Hubspot has you covered. Just make sure you are using the new design manager.
To answer some of your questions:
1. it is highly recommended that you create design manager files for all of your assets. You may never need to access them again but some you might and there is no point in splitting assets between your design manager and file manager. Also, like @tjoyce pointed out, using the Hubl functions like include_css() reference an id so the url can change and, in my experience, it is updated even in coded files.
The file manager has a lag to it when updating files. I have a json file Store in one of my clients file managers that I have to update on occasion. My process is to open the file in the browser, copy it an editor, change it, save it as a new file, upload the new file, and update the file reference in the code. v1, v2, v3, v4, v5.... it is tedious but there were times the file doesn't update for hours and uploading a new version takes minutes. Still, the design manager would have been better except that .json files aren't/weren't an option.
2. Static assets such as images, videos, pdfs, so on and etc. are perfect for the file manager. you can choose to use hubspot's cdn url or one of the urls connected to your portal with your files. Technically this means you can use relative urls however i do not see the point considering you are only cutting the domain name and their file names can be long depending on your file structure.
3. The Hubspot market place has some free templates you can download to a developers portal or your/your client's portal. You there is an option under "action" to clone to code or view source code. Your portal should also have the evast theme that you can do the same with.
4. Learn some python, or at least about routing. a normal website would have a folder structure and files would exists in paths relative to the structure. Routing changes the way that works. I feel like that might some how be relative to what you are looking for. Hubspot is built it python and HubL is very related to Jinja2 so l took some python courses on teamtreehouse.com and I feel like I was able to understand Hubspot's inner workings much better because of them. You just have to keep in mind that your server side scripting is limited to HubL and any tricks you can get out of it. That is different then cms's like WordPress or Joomla that give you access to the system core if you dare venture so deep.
5. Read the docs
https://designers.hubspot.com/docs/hubl/intro-to-hubl I have been building websites for almost 6 years and I have yet to complete a project with out visiting the documentation. Variables, functions, filters, module tags, and most of the basic to understanding HubL. It also give you a copy and paste advantage that will speed you up quite a bit.
You will want to avoid uploading script and css files through the file manager unless they are libraries that generally won't change. If it's active scripts or styles, yes, create a new file in the design manager and paste in the code. You can then reference those files relatively using the hubspot function to reference that asset.
You sound like you have some development chops. It can be wierd transition from the wastelands to an oasis, but Hubspot has you covered. Just make sure you are using the new design manager.
To answer some of your questions:
1. it is highly recommended that you create design manager files for all of your assets. You may never need to access them again but some you might and there is no point in splitting assets between your design manager and file manager. Also, like @tjoyce pointed out, using the Hubl functions like include_css() reference an id so the url can change and, in my experience, it is updated even in coded files.
The file manager has a lag to it when updating files. I have a json file Store in one of my clients file managers that I have to update on occasion. My process is to open the file in the browser, copy it an editor, change it, save it as a new file, upload the new file, and update the file reference in the code. v1, v2, v3, v4, v5.... it is tedious but there were times the file doesn't update for hours and uploading a new version takes minutes. Still, the design manager would have been better except that .json files aren't/weren't an option.
2. Static assets such as images, videos, pdfs, so on and etc. are perfect for the file manager. you can choose to use hubspot's cdn url or one of the urls connected to your portal with your files. Technically this means you can use relative urls however i do not see the point considering you are only cutting the domain name and their file names can be long depending on your file structure.
3. The Hubspot market place has some free templates you can download to a developers portal or your/your client's portal. You there is an option under "action" to clone to code or view source code. Your portal should also have the evast theme that you can do the same with.
4. Learn some python, or at least about routing. a normal website would have a folder structure and files would exists in paths relative to the structure. Routing changes the way that works. I feel like that might some how be relative to what you are looking for. Hubspot is built it python and HubL is very related to Jinja2 so l took some python courses on teamtreehouse.com and I feel like I was able to understand Hubspot's inner workings much better because of them. You just have to keep in mind that your server side scripting is limited to HubL and any tricks you can get out of it. That is different then cms's like WordPress or Joomla that give you access to the system core if you dare venture so deep.
5. Read the docs
https://designers.hubspot.com/docs/hubl/intro-to-hubl I have been building websites for almost 6 years and I have yet to complete a project with out visiting the documentation. Variables, functions, filters, module tags, and most of the basic to understanding HubL. It also give you a copy and paste advantage that will speed you up quite a bit.
I think some of my questions have stemmed from the fact I'm porting an existing CMS driven site into hubspot - with no prior knowledge, so it's a bunch of information to learn in a short time frame.
In any case - I now have a working base layout, with a homepage that inherits off'f that and a new page title module in place.
I think now its more about figuring out what custom modules I need - and to determine if I'll go down the path of either a) using our own layout files in HTML / Hubl format - or if we'll re-create everything in drag and drop templates and modules.
WOW!!! The site you referenced is AMAZING. I merely looked at for 30 seconds and could already tell it has all the Hubspot documentation in an way that is easy to navigate, detailed but easily digestable, AND in one location! I've spent a week looking for orderly Hubspot documentation llike this.
It wasn't as detailed about "everything Hubspot" as I initially thought it would be, but it is a clean, clear, and orderly documentation of the Hubspot Design Manager UI.
I initially was hoping it would include some tutorials about creating custom drag and drop email templates (tutorials are incredbily lacking in the specific Hubspot documentation scattered around the web), but I did like the little quizes that help to confirm I'm digesting the content fully.
If anyone can point me to some in-depth tutorials on building custom drag and drop templates and/or custom drag and drop modules, I would be greatly appreciative.
If you can convert the current site to html/css/js, by copying the source code or through some other witchcraft, You can plug it into hubspot by taking the code for each module and placing it in its own custom module. You then use custom module fields to make the content of the section editable. If there are similar sections throughout the site you can use this same module because you can change the content in the page editor.
Give create a design manager file for each of your css and js pages and attach them to a template on the left side bar of the design manager while the outer area of the template is selected. Now add the custom modules that are your sections and your framework should be intact. Just build the templates then build the pages.
custom module fields and field groups have a repeater option now, btw. Most other cms websites utilize repeater fields and Hubspot has them now too. Also keep in mind that currently jquery1.9 is hardcoded into the standard header includes required to make a template available for pages. Some frameworks and libraries require higher versions.
I have a new issue. Our existng templates use Bootstrap 4+, with the latest version of jQuery. Unfortunately - the bootstrap javascript, and a bunch of our own javascript - requires a newer version of jQuery.
Because we're using our own HTML layouts - can we in some way override the jQuery version?
Ah - I looked at the source of the page you linked. You're importing jQuery twice in the source - once at the top, being HubSpot's forced jquery version of 1.7.1 - and then again, at the bottom - being jQuery 3+.
Sep 11, 20186:29 PM - edited May 31, 20195:54 AM
Key Advisor
Template structure & relative paths
SOLVE
Correct but there are no errors. I need to do some maintainance to this site due to a change in a third party api and I might look into the lack of error being an error in itself but as far as I can tell the scripts aren't interfering which was the best I could come up with.
The problem is that Hubspot forms and ctas still/use to require jquery to load in the head. I think we were told they made improvements that changed this requirement but that version of jquery is still linked in the includes. I've tried things like swapping the src value but I don't remember landing on anything ideal. I don't have to do this often nor have I wrestled with it in a while. If you have your own solution you should share it here and mark it for others to find. this is a popular topic.
Sep 11, 20185:45 PM - edited May 31, 20195:54 AM
Key Advisor
Template structure & relative paths
SOLVE
I did, but I don't know how if I am being perfectly honest. That sounds dumb but I was in a crunch and when I got it to work I didn't look back. Here's the site in all it's bootstrap4 glory: http://www.americanselfstorageok.com/
@Cadriel - I have never tried to use a relative path for these since the HS file manager acts as a pretty good CDN which allows for faster load times. I would recommend using the full path whenever possible.