ultimate-jekyll-manager
Version:
Ultimate Jekyll dependency manager
250 lines (169 loc) • 11 kB
Markdown
⏺ Based on my analysis, here's my comprehensive naming and organization proposal for your Ultimate Jekyll
template system:
Proposed Naming Convention
1. Layouts Structure
_layouts/
├── core/ # (was: main/global/)
│ └── root.html # (was: default.html) - Base HTML skeleton
├── themes/ # Keep as-is - theme-specific layouts
│ └── {theme}/
│ ├── shell.html # (was: base.html) - Theme's main wrapper
│ ├── page.html # (was: default.html) - Standard pages
│ ├── legal.html # Keep as-is - Legal pages
│ ├── blog.html # Blog layouts
│ └── modal.html # (was: fullscreen.html) - Modal/overlay layouts
└── blueprints/ # (was: placeholder/) - Content templates
├── legal/
│ ├── terms.md
│ └── privacy.md
└── blog/
├── index.html
└── post.html
2. Includes Structure
_includes/
├── parts/ # (was: components/global/) - Core page parts
│ ├── head.html
│ ├── body.html
│ ├── foot.html
│ ├── nav.html
│ └── footer.html
├── widgets/ # (was: modules/) - Reusable components
│ ├── ads/ # (was: adunits/)
│ ├── forms/ # Contact forms, signups
│ ├── cards/ # Card components
│ └── media/ # Images, videos, embeds
└── themes/ # Keep as-is - theme-specific includes
└── {theme}/
└── blocks/ # (was: sections/) - Theme blocks
3. Assets Structure
assets/
├── themes/
│ ├── _base/ # (was: _template/) - Base theme template
│ │ ├── theme.js # (was: _theme.js)
│ │ ├── theme.scss # (was: _theme.scss)
│ │ ├── js/
│ │ └── scss/
│ └── {theme}/ # Actual themes
│ ├── theme.js
│ ├── theme.scss
│ ├── js/
│ └── scss/
├── css/
│ ├── core.scss # (was: ultimate-jekyll-manager.scss)
│ ├── main.scss # User's main styles
│ └── pages/ # Page-specific styles
└── js/
├── core.js # (was: ultimate-jekyll-manager.js)
├── main.js # User's main scripts
└── pages/ # Page-specific scripts
Key Benefits of New Names
1. core/root.html - Makes it clear this is the foundational HTML document
2. shell.html - Better describes a theme's outer wrapper than "base"
3. blueprints - Clearer than "placeholder" for content templates
4. parts - More intuitive than "components" for page sections
5. widgets - Better describes reusable UI components than "modules"
6. blocks - Clearer than "sections" for theme-specific content blocks
7. _base - More descriptive than "_template" for the theme template
Hierarchy Flow Example
Using the terms page example:
1. src/pages/legal/terms.md → uses layout blueprints/legal/terms
2. blueprints/legal/terms.md → uses layout themes/bootstrap/legal
3. themes/bootstrap/legal.html → uses layout themes/bootstrap/shell
4. themes/bootstrap/shell.html → uses layout core/root
5. core/root.html → includes parts/head, parts/body, parts/foot
Additional Organizational Improvements
1. Remove __temp directory - Clean up legacy files
2. Standardize file extensions - Use .html consistently (no .html copy)
3. Create a docs/architecture.md - Document the naming system
4. Add .keep files - In empty directories to maintain structure
5. Theme consistency - Ensure all themes follow the same structure
This naming system uses single, descriptive words that clearly indicate each component's purpose while
maintaining the flexibility for users to create their own layouts without conflicts.
⏺ Update Todos
⎿ ☒ Analyze current template structure and naming patterns
☒ Examine the layout hierarchy and component relationships
☒ Propose new naming conventions for layouts, includes, and components
☒ Suggest organizational improvements for the directory structure
> ok what should i name "src/defaults/dist/_layouts/modules/redirect.html"? I have
"src/defaults/dist/_includes/modules/adunits/adsense.html" notice how it is in an adsense subfolder. give me subfolder name
⏺ Looking at your structure and the new naming convention I proposed, for src/defaults/dist/_layouts/modules/redirect.html, I would
suggest:
src/defaults/dist/_layouts/utilities/redirect/redirect.html
Or if you want to keep it flatter:
src/defaults/dist/_layouts/utilities/redirect.html
The reasoning:
- utilities better describes technical/functional layouts (like redirects) vs content layouts
- It follows the pattern of your _includes/modules/adunits/adsense.html where the subfolder (adunits) categorizes the type
- Other utilities might include: utilities/error/404.html, utilities/maintenance/maintenance.html, etc.
If you specifically want just the subfolder name: utilities
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ > │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
? for shortcuts ◯ IDE disconnected
NEW
⏺ Great question! For organizing layouts within a theme's frontend folder, I suggest a hybrid approach that groups related
layouts while keeping commonly-used ones at the root level:
src/defaults/dist/_layouts/themes/bootstrap/frontend/
├── base.html # Keep at root - the main theme wrapper
├── page.html # Keep at root - standard content pages
├── modal.html # Keep at root - fullscreen/modal layouts
├── pages/ # Specific page-type layouts
│ ├── legal.html # Legal pages (terms, privacy)
│ ├── contact.html # Contact form pages
│ ├── error.html # Error pages (404, 500)
│ ├── blog.html # Blog listing/archive
│ └── post.html # Individual blog posts
└── formats/ # Alternative content formats
├── bare.html # Minimal layout (no nav/footer)
├── print.html # Print-optimized layout
└── embed.html # For embedded content
Rationale:
1. Root level - Keep the most fundamental layouts (base, page, modal) easily accessible
2. pages/ subfolder - Group content-specific layouts that correspond to actual page types
3. formats/ subfolder - Group presentation variants that could apply to any content
This way:
- base.html remains the foundation all others extend from
- Common layouts are easy to find at the root
- Specific page layouts are logically grouped
- It's clear where to add new layouts as the theme grows
For your current files:
- legal.html → pages/legal.html
- fullscreen.html → modal.html (at root, since it's a common pattern)
ok so for the theme-specific layouts, theres a couple things and that leads me to a question
So a theme's layouts will live in a folder like (for frontend) "src/defaults/dist/_layouts/themes/bootstrap/frontend"
- A theme will always have a base.html layout that is the main layout for all pages in that theme
- However, the placeholder/blueprint pages will need to use specific layouts like legal.html "src/defaults/dist/_layouts/themes/bootstrap/frontend/legal.html" and eventually even more like a 404 layout, a contact layout etc.
- but there are also some more generic layouts like "src/defaults/dist/_layouts/themes/bootstrap/frontend/fullscreen.html"
HOW DO I ORGANIZE THESE LAYOUTS inside a theme?
I need help re-organizing some things in my lib.
Review "src/gulp/tasks/webpack.js" to see how the files are being bundled and loaded and the path aliases used.
src/assets/js/ultimate-jekyll-manager.js
* This is the file that the CONSUMING project will load
src/assets/js/utilities
* This directory is DIRECTLY COPIED to the CONSUMING project so that scripts SUCH AS "src/assets/js/utilities/popupads.js" can be DIRECTLY LOADED IN A SCRIPT TAG (no webpack is run on these files)
src/assets/js/libs
* This directory is not copied to the consuming project OR packed with webpack. It is JUST FILES THAT ARE IMPORTED BY THE ULTIMATE JEKYLL LIBRARY ITSEF. An example is "src/assets/js/libs/dev.js" which is imported during development and has some logging and debugging features.
NOW HERES THE PART I NEED HELP WITH:
1. I have "src/assets/js/redirect.js" which is loaded by "src/defaults/dist/_layouts/modules/utilities/redirect.html". I would like it to be WEBPACKED but i want to put it in a folder that is AUTOMATICALLY WEBPACKED that is distinctly separate from the main library. I need help naming that folder or deciding on a better strategy for this.
2. While youre at it, help me decide if "src/assets/js/libs" and "src/assets/js/utilities" are good names or if they should be changed.
{% assign page-url-stripped = page.url | replace: 'index.html', '' %}
{%- if page-url-stripped == '/' -%}
{% assign page-url-stripped = '' %}
{% endif %}
page.canonical: {{ page.canonical }}|
{% capture action_icon %}{% if action.icon %}{{ site.icons[action.icon] }}{% endif %}{% endcapture %}
METHOD 1
html class=h-100
body class=d-flex flex-column h-100
main class=flex-shrink-0
footer class=mt-auto
METHOD 2
html class=
body class=d-flex flex-column min-vh-100
main class=flex-fill
footer class=
DONT FORGET THE FLOW (goes from top to bottom)
│ src/defaults/dist/_layouts/placeholder/app.html\ │
│ src/defaults/dist/_layouts/themes/bootstrap/frontend/fullscreen.html\ │
│ src/defaults/dist/_layouts/themes/bootstrap/frontend/core/base.html\ │
│ src/defaults/dist/_layouts/core/root.html\