Jonathan Lahijani

I recently launched Greenform llc's new website: http://green-form.com/ Designed by Durre Design. Similar techniques and approach on the frontend to the other websites I developed (Gulp-based workflow based off of Sage, Bootstrap, Animsition, MatchHeight, Slick Carousel, etc.). The main part of this website is the products section. ProcessWire really excels for for these heavy catalog type sites, among many others. It's the perfect choice. The search/filter feature was a little tricky, but I was able to pull it off Here is a screenshot of how the 'product' template looks in the admin: As you can see, I'm using the Profields Table fieldtype for the product variations. The end client and designer love the ease at which they can update the website. Training beyond how to log in wasn't even necessary since ProcessWire's default interface is straightforward. More details on my personal website: https://jonathanlahijani.com/projects/greenform/

Has anyone heard of gridmanager.js? http://neokoenig.github.io/jQuery-gridmanager/ I think this could be a good plugin to build a fieldtype around.

Great module. Feature suggestion: Would be great if the option to load the dialog could be done via a button on the CKEditor toolbar rather than having to right click to present the context menu. I feel it's too hidden that way.

I'm experiencing the same issue as Soma, except my images are JPG. In my generated thumbnails from my master images, the white becomes off-white. I also tried modifying config's imageSizerOptions, however this didn't fix the issue: $config->imageSizerOptions = array( //"forceNew" => true, 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? // changed from soft 'sharpening' => 'none', // sharpening: none | soft | medium | strong // changed from 90 'quality' => 100, // quality: 1-100 where higher is better but bigger // changed from 60 'hidpiQuality' => 100, // Same as above quality setting, but specific to hidpi images // changed from 2.0 'defaultGamma' => -1, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) ); One thing I also tried was to mess with the original image's color profiles and such in Photoshop and then regenerated new thumbnails based off of that, but that didn't work either. I have a suspicion that this has to do with WAMP's image processor?

Not using it yet, but I'm definitely going to be to moving away from WAMP since the VM approach is the more modern and flexible way.

A few weeks ago, Hashicorp, the company behind Vagrant, announced Otto: https://ottoproject.io/ I'm excited to give this a shot and have it finally replace my (embarrassingly antiquated) WAMP setup, although it's a still a very young and perhaps has a lot of kinks that need to be worked out at this moment in time. If anyone tries it out with ProcessWire, I'd love to hear your experiences about it. Jonathan

I had this issue a while back, just in case anyone finds it helpful: https://stijndewitt.wordpress.com/2014/01/10/apache-hangs-ie11/ The title of the post states it has to do with IE, but it doesn't.

Disabling xdebug makes a huge difference for me (WAMP).

http://modernrealestatesf.com/ Developed by Jonathan Lahijani Designed by Candy Muse

I hit this issue today as well. I have a page that has a regular textarea field (not CKEditor) and it contains an embed code with <script> in it. Just that alone in the field causes a 404 when saving a page. Probably some PHP setting I have to adjust.

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.

What order management system are you using with Foxycart? Orderdesk? Or a custom solution?

Official Announcement: http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/ Hacker News Discussion: https://news.ycombinator.com/item?id=10086651

It's now fixed, but a config option must be enabled: https://github.com/ryancramerdesign/ProcessWire/issues/1321#issuecomment-131525655

Look into using Babun, which is a pre-configured Cygwin: http://babun.github.io/

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 wantNow 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.

I'm currently reading up on PostCSS, which seems to be the future of CSS pre-processors (it's actually a "Post" Processor). https://github.com/postcss/postcss Anyone else using it?

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.

I think this broke with 2.6.11?

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.

The PageRender module provides you with an "options" variable that provides some useful information, such as filename, pageStack, etc. Does that mean you should avoid redeclaring a variable of your own called $options?

I like to keep things light. I'd say look into Foxycart or Snipcart, or Moltin. Either solution still allows you to use ProcessWire while handling off commerce functionality to those other systems. Or you could built it entirely in ProcessWire like I did. Not recommended unless you really want to get your hands dirty. A lot of re-inventing the wheel (although a good learning experience).

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: 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. 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). 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: Add Page Add Custom Link Menu Items Perhaps simplify how you can add pages to your menu: Remove the existing 3 methods: Pages (both ASM and PageAutoComplete), Custom, Selector 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. 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. 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. 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. 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. Now for the "Menu Items" section: 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. "Main" tab should be renamed to "Settings". Put as second tab. "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. "Delete" tab should remain as is. What do you think?

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

I do realize you can use a field's visibility settings to achieve this quite well, but are there performance or overhead issues with this approach?