UNPKG

ultimate-jekyll-manager

Version:
250 lines (169 loc) 11 kB
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\