Jonathan Lahijani

Fantastic. Been waiting very long for something that takes me back to the days of Rails migrations! I will be doing a screencast on this in my WP vs. PW series. Just in time!

For those interested in migrations similar to Rails and other web application frameworks, see LostKobrakai's Migrations module: https://processwire.com/talk/topic/13045-migrations/

I've got that covered for ProcessWire vs WordPress. Coming soon. It's very in depth.

Better late than never. I'm almost done with my WordPress vs. ProcessWire series. I have about ~8 videos left to make. I will be uploading all the videos to YouTube in a playlist. Need a couple more weeks to finish them off and add a little polish. Here are the videos in the series (not yet in the final order): Installation Pages Page Templates Custom Fields Custom Post Types Blog Documentation API Updates Client Help Plugins Forms Shortcodes Page Order Images Videos Themes Widgets Menus Global Settings and Options Page Caching Search Engine Optimization XML Sitemaps JSON Data Search Users and Roles Config File Multi-Language Data Migration Ecommerce Community Comments Revisions Admin Themes Command Line Interface Hosting Multisite Admin Section Performance Visual / WYSIWYG Editor Bootstrapping Admin Bar Composer Debugging Front-end Editing Page Builders Each video is about 3-10 minutes long and compares a feature in WordPress with the same or analogous feature ProcessWire quickly and concisely. For example, Shortcodes vs. HannaCode, Gravity Forms vs. FormBuilder, WP-CLI vs. Wireshell, WP Rocket vs. ProCache, WP's Menu Builder vs. Menu Builder, etc. Some are a little more in-depth than others. I do give WordPress a fair shake, try to remain objective and let ProcessWire's superior approach to features speak for itself. I will most likely be adding an intro video that explains the series as well with some background as to why I use ProcessWire instead of WordPress and the philosophical differences between the two. The goal is to get people, particularly advanced developers and web firms who know how to code and who are on the fence about switching to a new CMS, to quickly see all the analogous features that they are used to in WordPress done in ProcessWire. Hopefully they will get the warm and fuzzy feeling and explore our community further. If there are any topics you feel that I have missed, please let me know. Make sure the topic is specific enough to warrant a video of its own, as this series is a feature-to-feature comparison. Thanks

I read this article from WordFence recently. It gives you an idea as to how these attacks are done in detail. Worth a read/watch: https://www.wordfence.com/blog/2016/02/wordpress-security-attack-platform/

To extend upon what LostKobrakai said, by basic understanding of PHP, I would say: how to set variables how to use the if control structure how to loop through an array (foreach) how to output something (echo) Those basic concepts apply for any programming language and will be heavily used in your templates. Master those with PW's easy API and you'll be like 80% of the way there.

This is a good place to start: http://modules.processwire.com/modules/login-persist/

Regarding nested repeaters, would it be possible to nest the same repeater field under itself? It's currently not possible, but that would be awesome. A potential use case is for creating a custom menu builder purely with repeaters.

Just launched MWest Holdings: http://mwestholdings.com/ Designed by Durre Design. PW, Bootstrap, Sage Frontend Approach, Slick Carousel... Lots and lots of carousels! The main "collections" on the site include: Properties Case Studies Staff News Articles Press Releases Blog Articles Going to /properties/ defaults you to /properties/residential/ca The two segments after /properties/ are URL segments which are used to bring up the appropriate properties. The primary navigation is hardcoded given the different types of links (some are regular links, some are anchors, etc.). I find myself hardcoding most navigation menus these days given the specificity and unique needs of each site. The navigation rarely changes however so that hasn't been a problem in terms of ability for a client to edit it. More details on my personal website: https://jonathanlahijani.com/projects/mwest-holdings/ Jonathan

Thanks for adding PageListSelectMultiple. I personally think it should stay since it puts you in the page tree context (meaning you see the page/child structure), thereby making it easier to understand the exact page you are choosing.

A Page field allows you to add multiple pages to the field (given the right settings... Multiple Pages + ASM Select). You can also add a new Page from a Page field (assuming you've allowed that option on the field) and have it assigned to this Page field, or any other Page field. A PageTable field allows you to do the same as a Page field as I described, however if you create a Page from a PageTable field, it can only be assigned to that PageTable field... meaning Pages created from a PageTable field are not "portable" like pages created from a Page field. You can't add a page that was already created to a PageTable field (I'm not considering the edge-case whereby the pages are coming from children, which PW handles already). The nice thing about a PageTable field is its presentation capabilities which a Page field doesn't have. A Page field only has the "Custom format" labeling options, which although nice, is not as appealing as PageTable. If you want the portability of new created pages that a Page field gives you, but with the presentational capabilities of a PageTable field, that doesn't seem to exist. So, to summarize the above, should Page fields be able to have an option to present themselves like how PageTables do?

For question #1, there's a less complicated way to go about it. Create a Page field called "Favorites" (or "Subscriptions"). Templates allowed for this field should be: episode, series, and whatever else can be favorited. Add this Favorites field to the User template. Program the feature as needed. For question #2, the approach you outlined is pretty correct and the ProcessWire way of doing things (or you could also use Options Fieldtype, but I don't prefer it). I personally call it "Options" instead of "Tools" and pluralize the option types (Languages instead of Language, Durations instead of Duration). Then create Page fields as necessary.

Avoid repeaters. One problem / limitation with them is that each repeated item is of the same template. If you have a page with many sections that each have a different template, then repeaters are not the tool. Instead, use a page select (page or pagetable). The limitations of repeaters have been discussed throughout the forum. Given the advances of PW in the last few years, I would consider the Repeater fieldtype's use case to be diminished.

For people who want a simple solution out of the box, I would say ProcessWire is not that kind of CMS and that's a good thing. I see ProcessWire as a developer-oriented tool for building custom, complex content websites that have unique requirements and that should be it's strength. CraftCMS and ExpressionEngine fit that niche as well. If ProcessWire were to become a CMS where themes could be swapped at will, I'd imagine that would first pose some technical challenges that would need to be resolved. For example, to what extent does a theme dictate field/template structure, and if someone were to switch to another theme, how would that work? Nico's WireThemes proof of concept module has a nice way of going about that. It's similar to how FormBuilder can map a form's fields to a page's fields when using FormBuilders option to save submissions as pages. When it comes to WordPress and premium themes (like ThemeForest), once you're on a theme, you are stuck with it. No easy portability. Not to mention, each theme is like a CMS within WordPress itself, especially with the trend of mega themes that have recently become popular. Then when add a few plugins to the mix and you'll probably have all kinds of conflicts. Although WordPress is still the king of CMSes for ready-to-go themes, I would say that WordPress is going to be losing its dominance in that arena given the new generation of remotely hosted content management systems, like SquareSpace, Wix and Webflow. Those companies are doing very well because they really cater to people who want something up quick, cheap, easy and with a small learning curve. No coding required. It seems that WordPress (.com at least) is stepping up their game to challenge that. Their new admin system and Jetpack are good examples. Lastly, being the McDonalds of CMSs will cheapen the image of ProcessWire. I do think however we should be attracting advanced WordPress developers. In short, anyone who uses any tools from Roots.io, Underscores, Advanced Custom Fields, WP-CLI, or similar. There are many talented people in those circles who for reasons beyond me, still use WordPress.

Nice. So this is similar to the Templates Notes module, except the management of the docs is done via ProcessWire rather than HTML files. Would that be a fair way to explain it? One module idea I had around documentation was more of an admin help section not tied directly to a page template. Basically a PW version of WordPress's "WP Help" plugin: https://wordpress.org/plugins/wp-help/

There could be a situation where you want a Page with the following: it's published it's hidden it's template has a php file it SHOULD NOT be available to viewed on the frontend using it's URL Now you might be thinking "Well if you don't want it to be viewable on frontend, then just delete the template php file!"... however the purpose of wanting to have a template file could be for partial/section rendering. This is a pattern that I personally like to use. Here's a perfect example... let's say you have a page called "About Us" and it has 3 sections that make up the page. Based on how you want to structure that page, you decide that those 3 sections will be stored each as a child page of the "About Us" page, but when the "About Us" page is viewed, the page is built based on those 3 child pages (using a simple loop). So, we can give this as an example: /about/ (about.php)/about/philosophy/ (section-type-1.php) /about/mission-statement/ (section-type-2.php) /about/some-other-section/ (section-type-1.php) and in about.php, you might have something like this (using direct output)... <?php foreach($page->children as $section): echo $section->render(['prependFile'=>'']); endforeach; ?> and in section-type-X.php you would have just your partial markup: <section class="section-template-<?php echo $page->template; ?>"> <header> <?php echo $page->title; ?> </header> <?php echo $page->body; ?> <!-- etc... --> </section> So the above works fine, but those child pages can still be accessed if the direct URL is known. The way around this is one of the following: Option 1: In the partial file, detect if the page is being hit directly, as opposed to being rendered from another template like we are doing. If it it being hit directly, then redirect somewhere or throw a 404. You could do that by adding the following to the top of section-type-X.php. <?php // the pagestack is empty, which means the user hit this template file directly. if( empty($options['pageStack']) ): throw new PageNotFoundException(); // show 404 page endif; ?> Option 2: Don't assign an actual template file to the section templates. Instead, use a partial file approach So, you would rename section-type-X.php to _section-type-X.php (notice it starts with an underscore). Then in about.php, you would use wireRenderFile/wireIncludeFile. But now that I think about it, how would you best associate a section page with a template? -- Anyway, hopefully the scenario I outlined above helps someone. This occurrence, perhaps unbeknownst to @teppo may be happening on the weekly.pw site. For example, if you Google for just one Issue (let's say #32), you get the URLs not only to Issue 32, but the page sections that make up that issue: https://www.google.com/search?q=site%3Aweekly.pw%2Fissue%2F32%2F Results: https://weekly.pw/issue/32/ https://weekly.pw/issue/32/latest-processwire-core-updates/ https://weekly.pw/issue/32/new-module-service-ip-geolocation/ https://weekly.pw/issue/32/processwire-resources-of-the-week/ Is that a bug Teppo? You may get docked for duplicate content depending on how you are handling canonical URLs.

One thing I'm going to be working on soon is adapting Trellis to ProcessWire. If any of you saw my video on adapting Sage for ProcessWire, Trellis is a project by the same group of people (Roots) which allows for you to setup an excellent development + staging + production environment using Ansible (and Vagrant for the development environment). Because of the similarities between WordPress and ProcessWire (well, in terms of the server stack required and the fact that they are both CMSes), a lot can be borrowed from their setup in terms of approach and techniques. They use WP-CLI for some things, but Wireshell can be swapped out for that nicely from what I've researched. I'm really excited to see how it turns out because this has been a huge missing piece to my workflow. This approach would replace things like Capistrano and any other deployment methods, assuming you use a dedicated VM for a site. I highly recommend checking out Trellis to see how it's done. It's thought out very well.

I believe this as well and here's how I came to the same conclusion... I recently read this post by the original creator of Drupal and the fantastic comments there: http://buytaert.net/should-we-decouple-drupal-with-a-client-side-framework ... and that gets you thinking deeply about the evolution of content management systems and what their role is in the coming years. If you believe their role is ultimately some sort of structured content storage database that's decoupled from the frontend, or entirely headless, then platforms that like already exist. They are called Content as a Service systems, like Contentful: https://www.contentful.com/ More about CaaS: http://ecmarchitect.com/archives/2014/10/27/3944 Contentful is "an API-first CMS" and is entirely headless. It exposes the content as an API. You can then build your frontend separately in any way that you like. A very interesting approach is outlined here, using the Roots static site generator: http://carrot.is/coding/static_cms The thing about Contentful is that the concept and simplicity of fields, templates (known as "Content Types" in Contentful) and pages (known as "Entries" in Contentful) is almost exactly like ProcessWire. If you compare the two, you soon realize that ProcessWire is much more robust and feature rich... more field types, ability to nest pages, finer level of control, a User system, not forced into Markdown for rich text fields, ability to create modules, Hannacode/shortcodes and so on. Contentful is great too, but I feel it has a more precise use case. With that being said, the way I see ProcessWire is that it can be a CaaS-like/headless CMS much like Contentful, but also a "traditional" CMS like Drupal/WordPress but with way better architecture. Best of both worlds. I love my CMS too.

I don't know if there are many here either, but this will be a good way to find out, or convert . That's why I kept the group a little generalized by having "and CMS Web Developers" in the title.

I've created a group on Meetup.com for ProcessWire: http://www.meetup.com/Los-Angeles-Processwire-and-CMS-Web-Developers-Meetup/ (note: please don't join unless you're in the LA area or post cat pictures on the page) :: ProcessWire evangelist mode activated! ::

While we're on the topic of Capistrano, I thought I'd mention a project called WordMove which I found recently: https://github.com/welaika/wordmove

Here's a little Hanna Code snippet I wrote that allows you to insert a tag that contains any HTML element of your choice along with any attributes. The only defined Hanna Code variables are "element" and "comment". If you leave element empty, it will automatically use the "div" HTML element. The "comment" variable is optional and doesn't get outputted on the frontend. It is only for internal use and if you want to actually describe what the Hanna Code is doing. Import these two into Hanna Code: "tag" !HannaCode:tag:eyJuYW1lIjoidGFnIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxuZWxlbWVudD1cImRpdlwiXG5jb21tZW50PVwiXCJcbmhjX2F0dHIqXC9cbjw/cGhwXG5cL1wvaWYoIGVtcHR5KCRhdHRyW1wiZWxlbWVudFwiXSkgKSByZXR1cm47XG4kcmV0dXJuID0gJzwnLiRhdHRyW1wiZWxlbWVudFwiXTtcbmZvcmVhY2goJGF0dHIgYXMgJGsgPT4gJGEpIHtcbiAgICBpZiggJGsgPT0gXCJlbGVtZW50XCIgfHwgJGsgPT0gXCJjb21tZW50XCIgKSBjb250aW51ZTtcbiAgICBpZiggIWVtcHR5KCRhKSApICRyZXR1cm4gLj0gJyAnLiRrLic9XCInLiRhLidcIic7XG59XG4kcmV0dXJuIC49ICc+JztcbmVjaG8gJHJldHVybjsifQ==/!HannaCode "end-tag" !HannaCode:end-tag:eyJuYW1lIjoiZW5kLXRhZyIsInR5cGUiOiIyIiwiY29kZSI6IlwvKmhjX2F0dHJcbmVsZW1lbnQ9XCJkaXZcIlxuaGNfYXR0cipcL1xuPD9waHBcblwvXC9pZiggZW1wdHkoJGF0dHJbXCJlbGVtZW50XCJdKSApIHJldHVybjtcbiRyZXR1cm4gPSAnPFwvJy4kYXR0cltcImVsZW1lbnRcIl0uJz4nO1xuZWNobyAkcmV0dXJuOyJ9/!HannaCode Now for some examples: Example 1: Section [[tag element="section"]] will output... <section> Example 2: Section with class [[tag element="section" class="myclass myotherclass"]] will output... <section class="myclass myotherclass"> Example 3: Section with id [[tag element="section" id="myid"]] will output... <section id="myid"> Example 4: Section with inline styles [[tag element="section" style="color:red"]] will output... <section style="color:red"> Example 5: Section with any attributes you want (data attributes for instance) [[tag element="section" my-custom-attribute="test-value" data-something="cool"]] will output... <section my-custom-attribute="test-value" data-something="cool"> Example 6: Same as above with "element" not defined (defaults to "div") [[tag my-custom-attribute="test-value" data-something="cool"]] will output... <div my-custom-attribute="test-value" data-something="cool"> Example 7: Same as above with "comment" set (which does not get outputted) [[tag my-custom-attribute="test-value" data-something="cool" comment="Don't remove this line or your page will get totally messed up!"]] will output... <div my-custom-attribute="test-value" data-something="cool"> Example 8: Close section tag [[end-tag element="section"]] will output... </section> Example 9: Close div tag [[end-tag]] will output... </div> Example with a common Bootstrap rows and columns scenario: [[tag class="row"]] [[tag class="col-sm-6"]] This is the first col. [[end-tag comment="end of first col"]] [[tag class="col-sm-6"]] This is the first col. [[end-tag comment="end of second col"]] [[end-tag comment="end of row"]] -- Note the following article regarding the terms "element" and "tag": http://perfectionkills.com/tag-is-not-an-element-or-is-it/

Looks like Magento 2 was finally released a couple days ago. Anyone here a big Magento fan? I did a couple projects with it back in 2009 and 2010, however to me, it only makes sense if the project has a very high budget given how much of a headache it is to deal with. I'm all for using ProcessWire for ecommerce sites now. Works great for the catalog portion when combined with something like FoxyCart, Snipcart or Padloper if you're willing to get more involved with code.

Keep Response JS in mind: http://responsejs.com/ It's one of my go-to libraries on the frontend.

I've seen this issue before on the forums. I believe you have to use $config->paths->templates as part of your include. Alternatively, if you have a page that utilizes mysidemenu.php as its template file you could just use render, like: echo $pages->get("/path/to/page/")->render(); // add ['prependFile'=>''] inside of render if necessary