Leaderboard

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/

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

Can we all please give ryan the benefit of the doubt and assume it might have just been a mistake. If this would be an intended change of requirements – which seems unlikely from prev. strongly held support down to even 5.3 – I'd expect ryan to announce it properly. Also this is the branch of active development in the end and while it has been super stable in the past without any major issues it's still a development branch. I see it similarly as with beta versions of other software. Things might go wrong sometimes.

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

https://processwire.com/blog/posts/rebuilding-pw-website-part2/

Cool to see there are options to probably take away a lot if not all of the things I mentioned. I really think the option for having the site tree visually present all the time will be great for people who only edit their site once every month or less. But it is probably unwanted for people who really need to do a lot of work on pages and want all the space they can so cool that it's an option ? I will keep an eye on Processwire and I'll probably do another test some time soon to see what happens if I do some small tweaks to make the admin even more friendly for non technical people.

Agreed - I honestly didn't pay much attention because it said "coming soon" and I was happy to see PW included along with Wordpress and Joomla.

Thanks for sharing! I think I wouldn't buy a theme of a theme company that uses a bought WordPress theme for their own website ? Or am I biased?

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?

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.

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!

new is a reserved word until PHP 5.6. Its not allowed to use it as a function name. PW 3.0.117 requires PHP 7.0. @ryan I strongly recommend to announce the change of the requirements. (even for the dev branch) https://github.com/processwire/processwire-issues/issues/735

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.

Good notice Bernhard, I wouldn't either. About being biased . . . every time when I hear the word "wordpress" I get a bit jumpy . . . . but hey that's just me . . . . About biased coders I know, they like to joke around: "watch out - Im gonna stuff your laptop with wordpress code" - lol If somebody looks for html themes, it only takes 5 min. bouncing over the net and you find lots of good and free themes http://www.tooplate.com/

Themes for PW: https://prothemes.studio/

@bernhard I've finally had a chance to try out your module tonight for a project where we're loading pages into a large data table (200+ rows) and were hitting a wall. Using RockFinder I now have the initial page load down to ~2 seconds, down from ~7+ seconds! This is a fantastic module, Bernhard. It looks like it's really well thought out and has some really powerful features for building queries. I love how it extends PW's native selectors and allows you to return standard objects, making it easier to substitute this in for a regular $pages->find. Thank you for making this! I think I can answer my own question now... The main issue with creating Page objects is that page instantiation requires a trip back to the database. The initial $pages->find converts a selector into a SQL query which returns an array of matching page IDs. Then those IDs are used to go back to the database and get the pages (or pull them from cache if they're already loaded). Then for any page field requested that isn't auto-join, an additional database query is required. If you're looping through a lot of pages, that's a lot of DB queries! It seems like there might be a way to provide the functionality of RockFinder in the native PW core, as an option when loading pages. You would still end up with Page objects in the end (which in my case would be a huge boon since I like to extend the Page class with a custom class and methods for each template), but we could skip that second trip to the database (getting pages by IDs) if we could just tell PW which fields we wanted it to get up front. After that, any additional fields we didn't specify could be loaded with another trip to the DB, as they are now. That being said, I'm sure @ryan has a good reason for that second trip to the DB. But it seems like there must be a way that we could improve the speed of native pages, even if it is a hidden/advanced option with some caveats. One minor complaint: I noticed is that the module seems to fail silently and return nothing when it can't find one of the fields. It would be good to throw an exception to make this easier to debug. Edit: Another thought... Is there a reason not to use WireData and WireArray for the objects returned from RockFinder, in place of an StdObject? This would allow you to use WireArray's built in sorting and selecting features on the result set: $results = $this->database->query($this->getSql()); if($array) { $objects = $results->fetchAll(\PDO::FETCH_ASSOC); } else { $objects = $results->fetchAll(\PDO::FETCH_CLASS, '\ProcessWire\WireData'); $objects = (new WireArray())->import($objects); }

News Update - 10 October 2018 I know many of you are eagerly awaiting the next version of Padloper. I thought I'd give you a couple of updates regarding progress. First, I'd like to thank you for the feature requests and your support. As previously stated, it will not be possible to accommodate all requests and those that may be accommodated may have to wait till other releases. OK, to the update. The following have so far been achieved. FieldtypeProducts A new Fieldtype for storing products including their variants, if any. This allows for easy retrieval and storage of data and and API that makes it easy to filter, search, manipulate, update, etc product details. So..: $foo = $products->find("colour=red,quantity<10"); $bar = $product->first(); echo $bar->size; echo $bar->price; // etc Discounts We have a new discounts class that allows for 4 types of discounts each with generic and specific requirements. Percentage discount Fixed amount discount Free shipping discount Buy X Get Y discount In turn, as applicable, the discounts are subject to generic conditions including customer country,named customers, customers subscribing to your newsletter, global usage, customer usage limits, customers who abandoned carts, start/expiration dates, etc. There are also discount-specific conditions including whether to apply discount to entire order, specific products or specific categories/collections, minimum requirements (purchase amount or quantity of eligible products in cart), etc. Import/Export Products This class allows for importing products into your shop as CSV, JSON or arrays. It is 98% done. It will also allow for exporting products as CSV (and maybe in future, as JSON, if there is demand). MarkupPadloper This is WIP to eventually replace PadRender. This allows for retrieving products, product tags, product categories, etc, either as ready-to-render (i.e. includes the markup) vs retrieving the raw product details so one can use their own markup, anywhere, anyhow, to output products. Other A bit of work on customer notifications (including email templates) and FieldtypeOrders for orders plus some other stuff. I got a lot to do, so I better get cracking! ? Thanks for reading.

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

$all_match = true; foreach($items as $p) { $pp = $this->pages->get($p->product_id); if($pp instanceof RepeaterPage) $pp = $pp->getForPage(); if($pp->my_field != '3') { $all_match = false; break; } } // do something according to the value of $all_match

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 ?

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.

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

I have tried this extension before, but didn't like that it creates HTML tags too. Most of the time I just want the autocompletion of UIkit classes. Hopefully this will be added or someone else makes an extensions similar like the one for Sublime Text. But if you don't have an issue with that, it is a good extension. ?

The separate method is a good idea. Glad my suggestion was useful!

Hello @Epileptiker, there is the module Template File Editor that seems to let you edit template files from the back-end. I have never tried it, don't know if it is still compatible and wouldn't recommend to have such a powerful module installed on a live site, but if you really don't have FTP access, that module could help you to get your Google Analytics Tracking-Code in your template files. Don't forget to uninstall if you are done. ? Regards, Andreas

[I was asked to remove the link for now]

Not a direct answer to your question, but did you consider building a dashboard? i.e. a special page where you would have useful shortcuts for your admins, like "add news item", "add new event" etc. There are quite a few helpful forum threads with various suggestions how to build something like that.

@Zeka I would like to request adding a [SOLVED] to the title of this thread. This helps others who are looking for working solutions.

What @elabx said. And... ...is that intended to be a sub-selector? If so you need to use square brackets. $query .= 'guests=[party_guests>=1, party_guests<51], ';

Do you have PW's debug mode on? If not it suppresses PHP errors. Alternatively, TracyDebugger will in most cases display these errors even with debug mode off.

Apparently from what I find in the searches, it's just not going to work with text fields:

Hi Zeka and dragan, thanks a lot for your answers! I found out that changing the order of the language pages in Admin > Setup > Languages caused the problem. I had changed the order a while ago. As soon as I moved the default language (english) back to the first position, the tabs looked ok again. I don't know why that happens. Anyways, thanks a lot for your help!

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've managed to resolve the problem. I actually still think the issue might be a core ProcessWire one, but at least I know how to fix it now. Yes, I'm using the PW3 branch of Padloper, and it's working fine on other sites on my WAMP setup. I'm using AIOM+ on many sites with PW3 and it's working fine on all the others. I tried manually deleting all the entries in the cache table in phpMySQL and that allowed me to get into the site admin again temporarily, although it gave some notification about some modules that actually are present not being installed. I went to modules, and did a refresh, and the error came back. One thing I noticed that I wonder about, but don't know enough about how Processwire handles loading modules, is looking at the Modules.site/modules/ entry in the cache table, the modules seem to be listed in alphabetical order, and the offending module that is generating the error is listed before the module that it depends on, which it claims can't be found. I'd hope this shouldn't matter, as it could have serious implications for module naming, as the offending module was working previously, but it seems it does. I manually edited the order of the modules listed in the cache entry via phpMySQL, and the error went away. I've tracked down the issue with AIOM+ I think. There was a namespace conflct in that a reference to a root PHP class was picking up the ProcessWire namespace and obviously not working. I think I must have added a namespace statement to the module so that the module compiler didn't have to do it, but forgot to check any possible conflicts. The good news is AIOM+ works fine without namespaces in Processwire 3.x I think the AIOM+ problem might have actually been a red-herring with me trying to add namespaces to everything to try to get the first error to go away. The real culprit here is that if the Modules.site/modules/ gets regenerated somehow, it seems it can potentially break a site, as it will add modules in alphanumeric order, and if a module depends on another one that comes later in the sort order, then the class will not be found. This can be fixed with careful naming of modules so that a module that has dependencies will always be listed after any dependencies, so in the case of PaymentInvoice, since it depends on PaymentModule, it probably should have been called PaymentModuleInvoice which would ensure that regenerating the modules cache would always load it after PaymentModule.

Super useful module @thetuningspoon and @Macrura - any chance we could have the option for each page reference field whether the links should open in a modal, or straight into the current tab - I am wanting this as more of a navigation tool. Would this be easy enough to implement? Thanks!

id is a field of the page even though it's an InputfieldHidden one.

Hi! Will "Show this field only if" condition work for you? You could specify an id of a page on which you would like your field to be present. I am attaching a screenshot to illustrate my point.

LostKobrakai, thanks for help! Final solution wire()->addHookBefore("ProcessPageEdit::processSaveRedirect", function(HookEvent $event) { $url = $event->arguments(0); $page = $event->object->getPage(); if($page->template->name == 'blog-entry') { if($url == "../") { $goto = wire("pages")->get(3062)->url; $event->arguments = array($goto); } } });