Jonathan Lahijani

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?

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?

Another plugin that's similar to RAMP: https://github.com/stenberg/content-staging

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!

Haven't tried this yet, but worth looking into: http://dbv.vizuina.com/

One thing that would take this even further is if instead of having an "add new" button for each template, perhaps have a dropdown instead. This would work well in situations where one would have like 20+ templates types that can be added to a pagetable.

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

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.