Jump to content

Jonathan Lahijani

Members
  • Posts

    631
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Jonathan Lahijani

  1. It's been an extremely busy last few months for me, but I finally managed to launch Christopher Todd Studios:

    http://christophertoddstudios.com/

    I'm using my go-to frontend approach, which is based off of Sage.

    Some frontend packages I'm using include:

    • Bootstrap SASS
    • Animsition for the page transitions
    • Slider Revolution for the home page slideshow (using the Ken Burns effect)
    • Slick Carousel for the portfolio slideshows (with the lazy loading feature enabled... very important)
    • Ekko Lightbox for the video modals
    • Headroom.js for the navbar hide/show interaction
    • jQuery Lazyload for other image lazy loading (like the blog)
    • MatchHeight for some areas that need matched heights
    • ResponseJS for loading content when a specific breakpoint is hit (rather than it being loaded but hidden, which is bad for performance and sloppy; very important)
    • Linearicons

    I wrote the slideout navigation menu myself.  Just some CSS and JS.

    My goal was to make sure this site is fast and doesn't feel clunky.  I feel it has met that objective especially with the performance and optimizations that have been done (there's still a few I will eventually get to and squeeze out even more performance).

    In terms of ProcessWire modules being used:

    • FormBuilder is being used and it's submitting results to Tave, which is a lead management system.  FormBuilder made this easy with its 'Send duplicate copies to to another URL or 3rd Party Service' feature.
    • Image Extra
    • Social Share Buttons
    • Page List Image Label
    • Hannacode

    The original site was based on WordPress and had many blog articles.  Using Ryan's great writeup, I imported all the posts into ProcessWire.  The blog setup is self made and inspired by the Blog Profile (not using the blog module).  The original site also didn't have permalinks enabled in WordPress, so I wrote some code to capture the necessary URL variables and forward them to the correct page so that old links are maintained, which is also good for maintaining SEO.

    The client loves ProcessWire and its simplicity.

    • Like 8
  2. There's a variety of ways to go about it.  The approach you choose ultimately depends on how flexible you want it to be.  This is a situation I've faced many times, and my approach has become more and more refined over time.

    Approach 1:

    You could assume that there will always be those 7 sections, in their exact configuration and only on one page.  If so, you could simply code the section grid structures in your template.  As far as what goes in each block within each section, they can either be coded in the template file, or there could be custom fields representing each block, or a combination of the two.  This approach is not the most flexible, but would be the easiest for your end client to manage because there a 1-to-1 relationship (meaning each block is defined by a specific field).

    Approach 2:

    You could create a section system using the PageTables field as described in the previous replies above.  It would involve the following:

    Templates:

    • template: content-sections.php
    • template: content-section-type-1.php, -type-2.php ... -type-7.php (make sure to disable prepend of _init.php if using direct output)

    Pages:

    • /content-sections/ (uses content-sections.php; set this page to hidden)

    Fields:

    • content_sections (PageTable, allow use of content-section-type-1,2,3,4,5,6,7; pages created get stored under /content-sections/); auto-name based on a date timestamp; apply field to the template(s) you want

    Now edit the page that contains the content_sections field and create your 7 content sections.  Edit the template file that this page uses and output the blocks:

    <?php foreach($page->content_sections as $content_section): ?>
      <?php echo $content_section->render(); ?>
    <?php endforeach; ?> 

    Write the necessary HTML and CSS for each content-section-*.php file.

    Limitations of this approach are the following:

    • It forces you to assign the "content_sections" field to the template(s) that you want to use it on.
    • Due to the nature of the PageTable field, you can't re-use an existing content-section on a different page.  You'd have to re-create it the content-section. (a regular Page field allows re-use of existing pages, however the interface isn't slick like PageTable; look into this PageFieldEditLinks for an easy workaround)
    • In the event you want to insert a different kind of content between content-sections, that means you have to create yet another content-section type to handle that situation.  This will get intense if you have a lot of different situations.

    Approach 3:

    This approach is what I like to use if the situation is right.  Like Approach 2, create the templates and pages as described.  Now, if you want to create a content section, simply create it as a child page of /content-sections/.

    Now you obviously want to insert these content sections on your page, but since we're not using PageTables, we need a way to do this.  Hannacode to the rescue.

    Create a Hannacode called "content-section".  Give it a variable called "_name" (notice the underscore... "name" is a reserved word which Hannacode will complain about but no big deal).  Make sure it's a PHP Hannacode.

    Now we need to program this Hannacode to output a content-section.  This code will work fine:

    <?php
    $content_section = $pages->get("/content-sections/{$_name}/");
    if($content_section->id) echo $content_section->render();
    

    Now in your page, simply insert something like this in the body field:

    Welcome to my page.
    
    [[content-section _name="the-name-of-content-section-1"]]
    
    [[content-section _name="the-name-of-content-section-2"]]
    
    [[content-section _name="the-name-of-content-section-3"]]
    
    You can put text between content sections because we're just inside of a CKEditor field.  No limitations!
    
    [[content-section _name="the-name-of-content-section-4"]]
    
    [[content-section _name="the-name-of-content-section-5"]]
    
    [[content-section _name="the-name-of-content-section-6"]]
    
    [[content-section _name="the-name-of-content-section-7"]]
    
    

    The key thing here is how Hannacodes are being used.  Notice how I'm just calling on the render method, so the Hannacode itself is not dealing with the any complex logic.  It's simply being used to load a page with its template... nothing more.

    This approach is good because:

    • it'll allow you to insert content-sections on any page with a body (or similar) field, regardless of the template.
    • you can insert random content between the content sections
    • content sections can be re-used (unlike with pagetable)

    The drawbacks of this approach are:

    • you have to use hannacode, the syntax and know the name of the content-section you want to insert. (although this could be solved with some sort of ckeditor button... I wish there was a ckeditor hannacode smart inserter; apeisa has thought up this idea as well; SOMEONE DEVELOP THIS! :) )
    • because the hannacodes are just text, it's not a "true" relation behind the scenes.  so, if you were to delete a content-section (or change the page name) from the page-tree, the hannacode will still be present (unless some sort of special text formatter like the page link abstractor is made)

    --

    The thing about ProcessWire is that you can create any approach pretty easily based on your needs, and I think that's what it comes down to.  There's no "right" answer, but rather whatever suits the site the best.

    • Like 4
  3. It seems you unpublished the page?

    You are in the backend, one that only you can see, why does it matter to see a pretty URL?  :P OK, what is happening is this. When 'viewing' a page like the one you've created in admin, what you are actually doing is editing it...hence the .../edit/?id=1006. If you want something like .../admin/settings/ what you need is to create a process module or use some other modules available for PW. I am inclined to think, though (apologies if I am wrong) that you are a newbie to PHP as well? I am hesitant to point you to advanced stuff until you at least learn the basics of PW  :lol:

    Here's a tip for making your global settings / global options page easily accessible in the admin, without having to create a custom process module or going to the page using the pagetree.

    Let's say the page name of your settings page is called "settings" and it's directly under home.

    Now, create a *new* page under the admin page in ProcessWire.  Use the "admin" template.  Call this page "settings" as well.  After saving, it will now give you the option to choose which process module this admin page will utilize.  Choose "ProcessPageEdit".

    Now you will have a link in the main navbar to this Settings page, but when you go to it, it will error saying "Unknown page" + "the process returned no content".

    What you need to do is make this page load the /settings/ page you originally made.

    Using the special "/site/ready.php" file (create ready.php if it doesn't exist), you can add the following line of code to it:

    if($page->template=="admin" && $page->name=="settings") $input->get->id = $pages->get("/settings/")->id;
    

    Now go to the Settings page in the navbar.  Nice, easy and "official" feeling.

    • Like 8
  4. Thanks everyone for the welcome.

    I've been reading through many of the posts in getting started, api/module, etc., and the only question I have at the moment is in regard to the documentation and cheat sheet. I think I read that the cheat sheet is being updated, and the wiki is going away. Being the newbie, I like to try and find out the answers before coming here and wasting y'alls time with a rookie question. So, my question is, how up-to-date, or sync'd, are the reference materials in relation to the production releases?

    If you're running the dev version (which I like to do since so many amazing features make it into PW each Friday), then reading the blog is a must:

    http://processwire.com/blog/

    I'd say read at least the last 10 posts (better yet, all of them) and continue reading every Friday.  They get straight to the point and have nuggets of information that aren't in the Docs section.

    My opinion is the Docs are great and will get you far, but is missing other nuggets of specific information.  For example, you would never know there's a function called wireIncludeFile unless (a) you read it in the blog, (b) you somehow found a mention to it in the forums or © explored the source code a bit.

    • Like 4
  5. Hey @kongondo,

    I love this module and I'm featuring it in a comparison to WordPress's menu builder in my screencast series, however I feel there could be some general UI/UX improvements that can really make it feel more "native" and simplify what I feel is option overload.  Please take this as constructive criticism.

    Here are my thoughts:

    1. Perhaps remove the ability to create multiple menus.  It's a nice feature but it feels like overkill since sites typically don't have more than just a few menus.  (or disable this option by default and perhaps have it enabled in the module's settings for advanced used).  Perhaps add a standard "Add New" button instead that follows the typical Page creation process.
    2. For the same reasons above, remove batch actions to delete, unpublish, etc.  (or disable this option by default and perhaps have it enabled in the module's settings for advanced used).
    3. When going in to edit a menu, make the first tab be "Structure" which is selected by default.  This is typically the first action most people would want to take so it would feel more natural for it to be the first tab item. There should be 3 fieldsets/sections in this "Structure" tab:
      1. Add Page
      2. Add Custom Link
      3. Menu Items
    4. Perhaps simplify how you can add pages to your menu:
      1. Remove the existing 3 methods: Pages (both ASM and PageAutoComplete), Custom, Selector
        1. In regards to adding pages using Selectors, perhaps have this disabled by default, but an option that can be enabled in the modules settings.  It's an advanced feature but I'd imagine wouldn't be as commonly used and therefore feels a bit overwhelming.
      2. If possible, replace with a ProcessPageList (this is what goes inside the "Add Page" fieldset).  It feels like a more natural fieldtype since it uses the tree.
        1. since this would replace the ASM way of adding menu items, that means you can't change a CSS Class/ID until AFTER it's been added to the menu.  I think that's OK since right now you change CSS Classes/IDs both before and after adding the menu item, which I find a little confusing.
      3. If possible, upon clicking a page to add to your menu on the ProcessPageList, it should show an "add" action/button (native ProcessPageList action stuff), that when clicked, adds the page to the actual menu (some ajax/dom manipulation required here I think) instead of putting it in a "limbo" state like it is right now until a page is saved.
      4. As far as being able to add custom links, that should go under the "Add Custom Link" fieldset.  Perhaps also remove batch ability to add Custom Links and utilize general Inputfieldtext instead of a table structure.  Remove ability to set CSS Class and ID at this stage.
    5. Now for the "Menu Items" section:
      1. Right now, you're utilizing custom styling and javascript for the adding page items and creating the toggle boxes, however it should be possible to use make each added menu item act as an InputfieldFieldset.  When each item/fieldset is clicked, it should reveal the 5 editable fields (Title, URL, CSS ID, Class Class, New Window) and ability to delete.  Apply the nestedSortable JS to that list to make it have drag/drop capability with indenting.  A final result similar to this screenshot which I hacked together.
    6. "Main" tab should be renamed to "Settings".  Put as second tab.
    7. "Items Overview" tab: this could be removed (or disabled by default) since it's essentially just displaying the same menu in a table.  Feels repetitive.
    8. "Delete" tab should remain as is.

    What do you think?

    • Like 2
  6. Is it possible to use visibility settings to show a field on a specific page?

    Yes.

    Scenario 1: Let's say you want to show a field on all pages that are the child of a certain page.  In the visibility settings put:

    parent_id=id-of-parent-page-here

    Scenario 2: Let's say you want to show a field on a specific page. In the visibility settings put:

    id=id-of-page-here

    • Like 3
  7. I'm not sure if this has been brought up before, and I definitely know this idea is very wishful thinking since it goes directly against how ProcessWire is supposed to work, but I thought I'd bring it up anyway.

    Currently, if you want to add a field to a page, you must add that field to the template that the page uses.  This means, the field will exist not only for that specific page, but any pages that use the same template.

    Sometimes however, I want to add a field to a specific page without having to give that page a unique template.  Perhaps I'm a little lazy, or perhaps it just seems like creating a specific template feels like overkill, although that is the ProcessWire Way.

    If you are familiar with Advanced Custom Fields for WordPress, it does have this kind of functionality (in addition to a few other cool ways to assign fields), but WordPress of course handles custom fields in a much more "loose" way.

    Any thoughts on this?

    • Like 1
  8. Hey all,

    I wanted to see if there was any progress on this feature. I have recently had to use Wordpress on a project or two and while I can't really stand WP, there is an awesome plugin for syncing local and remote DB's (really any DB to another):

    "Migrate DB Pro" - https://deliciousbrains.com/wp-migrate-db-pro

    Something like this would be AWESOME to have for ProcessWire and really help with continuous integration workflows (Git does a great job of file sync, but DB is still a pain). Any thoughts on next steps for a module like this?

    Thanks!

    The WP Migrate DB Pro plugin doesn't do versioning (like Ruby on Rails DB Migrations) or content deployment (merging), but rather a complete database replacement of one database to another, which would be problematic on sites that are already live and whereby the live site and staging site have different content.  The RAMP plugin is what does selective content deployment.

    The current ProcessWire equivalents are a bit manual:

    • Can export and then import fields (native PW feature)
    • Can export and then import templates (native PW feature)
    • Can export and then import HannaCode (native module feature)
    • Can export and then import FormBuilder forms (native module feature)
    • The ProcessMigrator module does both field and template export/import along with the ability to export and import actual content.  So in my eyes, it's the currently the analogous plugin to RAMP.

    It would be very slick ProcessMigrator could "connect" a staging site and a live site so that content deployment could be one click.  Would be a great premium feature!

  9. Hi jsantari,

    Here's how I'd go about it:

    (1) Make the following templates:

    • products.php
    • product.php
    • product-categories.php
    • product-category.php
    • options (no need for php file)
    • option (no need for php file)

    (2) Make the following page structure:

    • /products/ (uses products.php)
      • /product-1/ (uses product.php)
      • /product-2/ (uses product.php)
      • (etc)
    • /product-categories/ (uses product-categories.php)
      • /product-category-1/ (uses product-category.php)
      • /product-category-2/ (uses product-category.php)
      • (etc)
    • /options/ (uses options.php)
      • /colors/ (uses option.php)
        • /red/ (uses option.php)
        • /green/ (uses option.php)
        • /blue/ (uses option.php)
      • /sizes/ (uses option.php)
        • /small/ (uses option.php)
        • /medium/ (uses option.php)
        • /large/ (uses option.php)

    (3) create the following fields:

    • color (Page field; single value; use /options/colors/ as parent; regular select box); assign it to product.php
    • size (Page field; single value; use /options/sizes/ as parent; regular select box); assign it to product.php
    • products (Page field, multi-value; use /products/ as parent; ASM select or even better, PageListSelectMultiple since you have over 2000 products); assign it to product-category.php

    Now we need to handle what you said:

    "The twist is that each product category will have attributes like color, size etc. but the values for color, size etc. will be different based on what category is selected."

    The way I'd approach is to create 2 more fields and assign them to the product-category.php template:

    • filterable_colors (Page field; multi-value; use /options/colors/ as parent; ASM select preferably); assign it to product-category.php
    • filterable_sizes (Page field; multi-value; use /options/sizes/ as parent; ASM select preferably); assign it to product-category.php

    So those two filter fields will pretty much allow your category to have specific filters.

    Ideally, you would then code your product-category.php template to loop through and output all the products assigned to the category, as well as loop through the filterable_colors and filterable_sizes which would act as filters to the list of the products on that page.  If doing the filtering client-side, here's a cool library:

    https://mixitup.kunkalabs.com/

    Hope this helps!

    Jonathan

    • Like 6
  10. What I think is most promising is using CKeditor widgets for image positioning, galleries, videos, text-columns, content highlights etc... and then just regular pages and repeaters for everything else (like featured products, carousels etc). Probably the ultimate solution would be something that ties hanna codes with CKeditor widgets.

    For me using repeaters and field dependencies here feel little hackish - both UI and backend wise.

    Looking into this further... CKEditor widgets does seem like a superior approach... much better than Content Templates (which I mentioned in my last reponse) since with Widgets, the HTML structure is locked and easy to reposition.  Very "page builder" like interactivity.

    There's some activity with Drupal and CKeditor Widgets that looks nice:

    http://albatrossdigital.com/node/41

    CKEditor also has demo:

    http://ckeditor.com/demo#widgets

    A combination of CKEditor Widgets + ProcessWire tie-ins would be pretty slick.

    • Like 1
×
×
  • Create New...