Leaderboard

Another "me too" from here. In fact when @apeisa first introduced me to ProcessWire, I wasn't that enthusiastic about it (some things about templates and fields just didn't seem to make sense), but having Ryan walk you through all that was a real game changer. We could use an updated video, though ?

Continuing work on the new ProcessWire.com, this week we discuss the documentation section of new site as more progress is made: https://processwire.com/blog/posts/rebuilding-pw-website-part2/

This one? https://processwire.com/videos/overview/ Love that video. It was my first contact with PW and after seeing it I was sold.

Thanks for your work on docs, @ryan! Actually your way of presenting and explaining things is as an important feature of ProcessWire as its beloved API. I remember being "hooked" after watching that gentle introductory video, way before I understood anything (could not find it to link here, is it gone?) Nowadays forum newcomers do not get much direct response from you (except for pro boards - and that is another reason to buy Pro modules ?), so probably even do not know about your way of turning answers to simple questions to profound mini-tutorials, often with some philosophical background. And that makes this documentation updated by you even more meaningful (Luckily those forum gurus that handle most of the never-ending questions are still inspired and hold the spirit of wise goodwill that make this place so great to be at). And those connections between established documentation and the constantly updating blog you wrote about are not only the new way to obtain more knowledge, but also a way to show the power of ProcessWire Page field in action on a site that should be an outstanding example of the system. The only thing i wish would happen but not yet happening is a community collaboration on creating, updating, linking the contents of the site, as well as designing and building it. You did say that the latter is about to happen, we do not discuss the former too much. So I suggest we think about the means by which the community can help you better in maintaining the docs and updating them gradually, so they are always up to date. These times most collaborative documentation is written under some kind of source control systems like git and afterwards presented with static site generators. I doubt this is a good way to go for a CMS project like PW (we should be eating our own dog food). But maybe we could use a mechanism of keeping contents in github and importing it to PW docs site when it is upgraded? Like the one use in ProcessWire Recipies website? That way we could help. And that is probably one of the best way to make happen the docs translation you talked about in the last post. Do you think we should explore this, or maybe you have something more profound already planned?

I have never seen this video before. How did I miss it!? Anyway, watched it in full. Great stuff! Yeah; had that thought when watching the video Forgetting the GUI for a minute, one thing that hit me was that I'd still choose ProcessWire now in 2018 if it was still at version 2.0. You can't beat the underlying architecture, philosophy and approach. Even 8 years later, ProcessWire is still API-centric. It's amazing though how much further along ProcessWire has come since ?

Having a compile step in software does allow for optimizations in the deployed endproduct, which just wouldn't be possible without it. To run that compile step for javascript one simply needs node, because e.g. a browsers runtime is even harder to get hold of. CKEditor is by it's functionality already tending to be a big package and it really needs to optimize every inch in it's package to save on download times and other performance critical parts of itself. That's the nature of anything you ship directly to the browser of your users. Part of that is modularizing code, so every bit of unused code can just be excluded from the shipped build. The downside of compile steps is that you often cannot directly hack on the end product anymore or it's way harder to do so. But would you rather have a hackable product, which performs worse for your endusers because of missing optimizations or a product, which requires you to setup a build environment, but builds a optimized package, which is not hurting your user's perceived performance. This is not to say node is super great. It does what I described above in a often super (and maybe unnecessary) complex way, but I wanted to give a bit of argumentation on why we see that trend.

// in your department.php template file foreach($page->child('name=meet')->children() as $person) { echo "<li><a href='$person->url'>$person->title</a></li>"; }

@OLSA Thanks for your insights. After reading many github comments and parts of the documentation and also trying out different things, I want to summarize some conclusions: CKEditor is not an HTML editor. It is a content editor and HTML is just one of the possible outputs. (From the lead developer) CKEditor 4 uses the DOM as a model. When loading data, the HTML is processed (read – filtered, normalized and escaped) but it ends up in the DOM anyway. CKEditor 5 has a custom data model. When you load HTML into the editor, it's parsed and then features (initialized previously in the editor) try to pick up from this HTML the pieces they understand. This is called "conversion". As a result of a conversion, the content is being loaded into the custom data structure. The reverse process is executed when content needs to be rendered back to the DOM (either for editing or for data retrieval). Read the complete comment here https://github.com/ckeditor/ckeditor5/issues/592#issuecomment-335108129 There is no no "View source" button to edit the HTML output directly, because you are not working with HTML, but a custom data model instead. There is no option to insert custom tags or javascripts in the content. Or we have to use placeholders and replace them. Or someone writes plugins for them. Custom attributes like data-something on elements are not implemented atm but you could write a plugin to extend this feature. CKEditor 5 is not meant as a replacement or upgrade of CKeditor 4. There may be content loss if you try to use existing content produced by CKE4 in CKE5. Read https://github.com/ckeditor/ckeditor5/issues/592#issuecomment-399361490 Table Plugin is very basic. No option to add a class to the table or specific rows/cells ? No target attribute on hyperlinks, like OLSA said. You can not add classes to elements like paragraphs, or words, etc. You could develop a plugin for this, but this has to be done for every element as far as I understood. My conclusion is, that CKeditor 5 may not be the best option for most of us. I will close the feature-request on github with a reference to this comment.

Maybe you got me wrong: I was just saying (or trying to say) that I guess that everybody knows it, because the admin uses it. It was in no way forcing anybody to use it. Always ? But it's a little offtopic imho. And the link shows just a graph like this one... Bulma looks also great though ?

Ryan, you're an absolute champ for grinding away on the documentation. We all know it's a developer's favourite task. But seriously, thank you.

Last few days I am playing with CKE5 inside PW, and here are my first impressions with it. First, what is important to say - CKE5 is totally different product compared to CKE4, but that mostly from development perspective. V5 use different data model, MVC architecture, and for any kind of customization (development) be prepared to use Node.js with dozens of packages. By default, CKE5 has explicit and strict HTML API and right now, as example, you can't set "target" attribute on link (!) and here and here are answers how that can be done. Also, the same goes if you need to place "data" attribute to some DOM element. "View Source" button (option) will never again by default be part of CKEditor and here you can find the answers for that task. Development of my first CKE5 plugin was not a nice experience, as example I build "ViewSource" plugin, but after a while realized that, in this very stricted data model, it is useless. To get some advanced options (eg. insert "target="_blank") need to develope and additional plugins (npm packages). On the other side, this new API provide options to works with content on different ways and maybe that is the best part of new CKE5 editor. As example, in theory, we can store in JSON but with single click that content can be converted to some Markdown or HTML and vice versa. Or maybe we can get option to store content in 1 cell but "descriptions" in other etc... Regards.

I would LOVE to see something like Gutenberg inside of PW. I think I remember there was a post about integrating it somewhere here in the forums. A drag 'n drop "Page Builder" or "Content Builder" was often requested here and most solutions that excist at the moment (including Repeater Matrix), are suboptimal in my eyes, but they get the job done, which is fine. I also love the editor from Dropbox Paper. A solution like this could be a huge step forward for ProcessWire. I think the approach of building Content/Structure instead of HTML (like CKEditor 5 does) is a good one, and it would eliminate many errors that are being made by users that have too much options in content editor fields (CKEditor, TinyMCE). But now CKE5 it is too restrictive, because many options mentioned before are missing. If we are using a content builder and the content would be stored not as HTML but in a structured array like bard does it, we would have a convenient way to edit and add content and still can control how the content is displayed on the frontend.

No, it's selectors as associative arrays: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#new-selectors-as-associative-arrays

I'm wondering if it's time we considered other editors? Maybe this though is premature...

On the department page, simply this: // $page = department A or B $persons = $pages->find([ 'template' => 'person', 'has_parent' => $page, ]); And for an overall overview: $persons = $pages->find('template=person');

Yep, another me too here. On the first day getting contact to PW, I saw this video and it put me on fire to try it out and to understand it. And some time later, after finding this "PW-spirit" in the community, to contribute to the image handling. (Thanks @Ivan Gretsky, for reminding on it. ?)

Isn't this already possible? It is a module like any other.

Inline with my last comment, I am thinking about adding an alert (with orange icon) when there are new properties/methods available after you upgrade to a new version of PW. Haven't decided on the exact interface yet, but if you like the idea and have any thoughts, feel free to suggest, but probably a simple note at the top of the panel detailing those new options and also highlighting in the tables. Probably with an option to "acknowledge" that you've seen the options to remove the notice. Something like that anyways.

@BitPoet, what do you think about changing from SQL timezone support being a strict requirement for installation to it being a strong suggestion? My shared hosting server doesn't have timezone data but if I comment out the WireException in the install() method then things seem to work okay. The field values are saved with the correct date and time in the database and I can match pages as expected. Not sure if that means that the server's SQL and PHP are set to the same timezone (not sure how to test that). The only issue I noticed is that with the "Default to today's date?" option selected in the field config the field shows an invalid date before a date has been entered: Would that be due to the missing timezone support?

Great idea on linking the blog posts to the docs pages. I’ve been using the blog more than the docs pages lately for finding documentation of new features, which is fine if you keep up with the blog like I do, but most newcomers are sadly not aware of these features!

Brand new numParents() method from the latest PW dev showing up in the API Explorer ?

This module provides a way to rapidly generate Page fields and the required templates and pages for use as a drop down select (or any other Page field type). This module will let you create a full page field setup in literally a few seconds To use, run Page Field Select Creator from the Setup Menu Enter a Field Title, eg: Room Types Select Options - These will become the child pages that will populate the page field select options. There are two different options. Option 1. TITLE FIELD ONLY - enter one option per line, eg: Single Double Suite Option 2. MULTIPLE FIELDS - the first line is used for the field names and the first field must be 'Title'. Subsequent lines are the values for the fields, eg: Title, Number of Beds, Number of People, Kitchen Facilities Single, 1, 1, Fridge Only Double, 2, 2, Fridge Only Suite, 3, 6, Full Kitchen Choose the parent where the page tree of options will be created, eg a hidden "Options" parent page Select a "Deference in API as" option depending on your needs Choose the input field type Check whether "Allow new pages to be created from field?" should be enabled. As an example, if you entered "Room Types" as the field title, you would end up with all of the following automatically created: a fully configured page field called: room_types MULTIPLE FIELDS OPTION - 3 additional fields - number_of_beds, number_of_people, kitchen a parent template called: room_types a child template called: room_types_items (with either just a title field, or with the 3 additional fields as well) a parent page called: Room Types a series of child pages named and titled based on the per line entries in the Select Options textarea The templates are configured such that the "room_types_items" child template can only have the main "room_types" template as a parent, and vice versa. Then all you have to do is add the newly created page field to any template you want and you're ready to go! You can grab it from: Modules directory: http://modules.processwire.com/modules/process-page-field-select-creator/ Github: https://github.com/adrianbj/ProcessPageFieldSelectCreator

I love the uikit css framework and everybody here should know it since the admin is built upon it. Here are several other great projects around the uikit framework, like free templates, IDE code snippets, starter kits, and also a backlink to processwire ? https://github.com/uikit/awesome-uikit

Very interesting topic. I surely can relate to the thing that the new CKEditor 5 seems weird for those used to work mostly with html and DOM (like myself). But I can see that it is very much in line with content editing principles @ryan initially put in ProcessWire. By default we can't put too much raw html and especially js in CKEditor fields. This stuff all gets striped out if you do not take time to configure otherwise (and this configuration is not that easy if not just simply turning everything off). So it might be CKEditor 5 is the best choice for content editing as defined by PW by default. And it can be configured even easier (by those who know how to). The main problem I can see is that there may be lack of developer's experience to get it all right for PW, as most of us here seem not to be easy with modern js development workflow.

Hey @LAPS from my experience I can say that you would better go with @bernhards RockPDF. WirePDF and the included mPDF are outdated and don't work with PHP >= 7. RockPDF uses the latest version of mPDF and also provides a debugging feature. However, I also updated mPDF in wirePDF and made the module itself compatible with the new settings but then switched to RockPDF. Eventually I will make a PR on the github repo.

This might be interesting in combination with e.g. a matrix field though. Have the nice UI of a "text-editor", but the (often not negative) restrictions of properly managed content types. I'm not sure how those plugins for content-types are managed, but if it's at runtime it could talk to processwire for that.

I actually came to that conclusion too. The latest release outputs an error message but doesn't throw an exception anymore. There are also instructions on the module config page how to set the correct offset through dbInitCommand in site/config.php so the global timezone in the MySQL server doesn't have to match that in PHP. I'm going to look into that one.

Yep, using an own admin module is possible since at least PW 2.0, if I remember right. ?

You are safe to skip this warning while you are sure you don't have a script that need to run longer than the limit (e.g. a custom cron job which in this case will fail silently). If you don't have lot of modules or your site's size isn't that "big" then you are again safe to ignore it. A small note about this specific warning coming from the FileCompiler.php to try to find out the culprit (imho, in your case, it come from a module) : Read on https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/#file-compiler-updates Call to set_time_limit() in ProcessWire 3 : https://github.com/processwire/processwire/search?q=set_time_limit&amp;type=Code

+1 Bluma looks great too, however, UIkit 3 has more features at first sight, but I admit I never used Bluma so I cannot tell for sure. UIkit 3 both supports LESS and SASS which is great in my humble opinion (I tend to prefer LESS to SASS). Anyway, Ryan had to pick a css framework and UIkit 3 is an actively developed, popular one, full of extendible and configurable features others do not support. It was a good choice I think ?

Work continues on the new processwire.com website, while the core received several updates including support for Markup Regions "pw-optional" attributes, upgrades to WireArray that make it a lot more useful, and more. https://processwire.com/blog/posts/processwire-3.0.117-core-updates/

It works again with PHP 5.6 @ryan Thanks for providing a quick solution. ProfieldsTable is working as well. But it remains an inconsistence. https://github.com/processwire/processwire-issues/issues/729#issuecomment-433594449

Me too!

I have not really dun in too much on the integration of uikit on the admin side. I like the updated color pallet much more than past versions, I really just need the layout to be responsive for mobile and for it to look somewhat decent. It could have been built using picnic.css, the current pallet, and some custom mixin styles and I would still love the admin. I for one am moving away from giving access to the admin for users and building my own "admin" on the frontend so users never even see the default admin. It lets me show only what I need to show and define my own actions for them to take. I do not mean to sound like I am knocking on the backend/uikit, but I like to have full control over everything presented/styles. On that last point, I do wish theming was a bit "Easier" for the admin.

Glad you are lovin it. Processwire is decoupled so everybody is free to chose his love on the front end. Critical thinking allowed ? I wonder who among us would have loved not to see Uikit in Processwire https://www.npmtrends.com/bulma-vs-foundation-vs-uikit

Thanks @ryan - excited to see it. Regarding the new "numParents" method/property, you are missing the @property in the Page.php doc comment.

Thanks for your short summary, it has opened my eyes... No source code editing? No target on a link? Are they serious? I think this Node.js craziness is sucking the fun out of web development. Sometimes a little bit of hacking here and there can solve something just right and the job is done. Why is this movement of over-engineering anything we can? When fiddling with the tool takes more time than doing actual development, then things are getting no longer enjoyable. And on top of all these, they remove features I rely on. I certainly do not need CKEditor 5 if things are going in this direction ?

Hey @thetuningspoon I just tried your suggestion about the WireArray/WireData... It's awesome ? I did it a little differently though, because my RockGrids don't work the way you implemented it. v1.0.9 introduces a new method: $finder->getWireArray(); This will return a WireArray containing WireData objects just as you suggested: For anybody wondering what this update could be used for: You can use all the pw api magic on that objects: New version is on GitHub - I'll change my public projects to github to have the PW modules directory automatically in sync: https://github.com/BernhardBaumrock/RockFinder/commit/46377ba6ea399f8557893684da3c3dd486b2c44e

Lots of improvements to the API Explorer have been committed and as far as I can tell it should now include all methods and properties for all PW objects and classes. It's now definitely ready for primetime although I am sure I'll think of other improvements to add ? Honestly I am learning about lots of methods/properties I didn't know about! Hopefully you guys will find it the best first stop for api docs.

A bit of an update after some more experimentation tonight. I added pages.templates_id as a field always selected in the RockFinder results, and then attempted to use the $pages->newPage() method to take the results of the SQL query and convert them into a PageArray of Page objects. This worked, thus eliminating that second trip to the database I mentioned (and also bypassing the page cache and probably some other nice features of the normal page creation process). Unfortunately, this slowed the whole thing way down again. So I'm thinking now that it is something else about constructing Pages that is slow. Maybe generating the page path or some other properties are the problem. Perhaps I need to load up some additional fields up front. Will have to test more. WireData/WireArray works great, though.

I really meant "to be installed as module". "Being able to install something" might not matter, but how one is being able to install/configure something might indeed matter.

Thats not practical since the "overrides" would need to be at so many places. With Uikit you've got LESS where you inject your colors etc. at various places. You replace code, not just override it. Simple overrides would be much more complicated and and could potentially break on an updated base theme. Replacing the whole CSS makes sence. BUT, you're suggestion just triggered an idea: Publish it as a propper Module and replace the CSS of the AdminThemeUikit with a hook… This way, AdminThemeUikit would still be technically the Theme, but the CSS (and potentially JS) would be entierly replaced by the "Child" Theme. In this way, one would also not need to change Settings etc… Brilliant! But I think, the required Method is not (yet) hookable… I guess it is hookable, since it's public…

I love ProcessWire. @ryan has done such a fantastic job and I'm sure is incredibly proud. I agree with some of the other members here that a goal of 2018 should be better community and project management in order for the community to grow and be part of the larger web development community. We do have our own way of doing things here which is fantastic, and the accessibility of ProcessWire is on point, but I fear we do lack some elements that can position us more, for lack of a better term, professionally. Here is my suggested list of priorities: Long-Term Vision: What is the long-term vision of PW? All the rest of my suggestions are coming from my long-term vision of how I wish to use PW, how I want PW to be seen by my clients and how I want PW to be viewed by other developers. But if Ryan doesn't want PW to get too big, if he doesn't want his role to become more and more of a manager and less of a sole developer role then that is fine. I can see a potential future where PW runs itself, where we have set up a structure for a team to surround Ryan, the community grows and lots of people buy Pro Modules =D New Website & Documentation: First impressions count, a consistent and modern site will help PW look like a real legitimate offering from the offset. Wouldn't it be fantastic if the ProcessWire website was open-source on Github - as the perfect demonstration of PW itself. Documentation needs to be positioned as a source of truth instead of scattered across multiple blog posts / forums posts. The API CheatSheet is great but we documentation also needs to provide standards and methodology for some of the most common solutions people build with ProcessWire. The MeteorJS Docs are a fantastic example - they include a full API breakdown as well as a guide for common areas such as Application Structure, Data management, user accounts etc. https://docs.meteor.com/ Importantly they are open-sourced on Github, so the community can contribute. Project & Community Management: Continuing from the above this should not all be put on @ryan's shoulders. I think much of the website and documentation above can be handled by the community once the initial setup is there. Slack Channel: We're modern so let's have a modern Slack channel. Team Members: Let's take some of the talented members of the PW community and give them a role if they want it. Who triages the Github issues, who can speak on behalf of the PW project that isn't Ryan? One Github Repo for PW: I don't understand the multiple repos for different things. Most projects don't go down that route? Contribution Guidelines: How to contribute to Processwire core. What are the coding standards, what issues can people currently contribute to? Open up the shop: Pro Modules should be available to the public, modules like Padloper should get seen on the PW site - after some requirements are met. Developers should have an easy access to earning from supporting PW instead of just consuming PW. PW should take a tiny cut of sales as well Stability and Modern Practices: If PW is to be part of the larger ecosystem we have to play on some of their terms. There has been great progress with this with Namespaces, and the new Admin theme etc. We should definitely focus on fixing some of the small issues that others here have mentioned and the development cycle. We should definitely be supporting NGINX as a first party citizen. On a side note; is PW unit tested? This is a big thing for larger developers. Anyway, I love ProcessWire but I feel that the community is actually quite fragmented, each of us doing our own thing in our own way in silos where the only commonality is that we consume the same framework. Lastly, @ryan - set up a PW Patreon. I'd happily subscribe in order to help support the development of PW technically as well as the project and community.