Leaderboard

Hello, Just a mention that today I have received this newsletter from The Whale : https://thewhale.cc/91 And Processwire is part of it ?

@Robin S, that works (in some cases) as well, but there are two reasons why I mentioned runHooks: Direct method call will cause an exception if myEvent hasn't been added as a hook method, runHooks won't. In this sort of scenario (events and listeners) the one emitting the event can't reliably know that someone is indeed listening, so this makes more sense. Direct method calls require that the name be a valid method name, runHooks doesn't. Notice how I used 'event-name' in my example? ? First one is really the key reason, second one is just a little quirk that one might find useful, i.e. it's easier to make sure that your event name can't accidentally clash with a real method. Note: runHooks is tagged with #pw-internal. I've used this before in my code because I really needed it, but it's officially not a part of the public API, and thus in case Ryan decides to alter the implementation at some point, there's a chance that code relying on this feature may need revisiting. Just saying. Using only "official API methods" one would have to either check hooks with getHooks before calling the method (directly or via __call()), or just call it and handle possible exceptions with try ... catch.

Example with 'body' field. Define a language fallback order in ready.php and render first match in template. (not tested ... ) // in ready.php $languageFallback = [1046,1042,1033]; // array of Language-IDs in fallback order $body = ''; $pageActiveLanguageIds = $page->getLanguages()->each('id'); $languageFallback = array_intersect($languageFallback, $pageActiveLanguageIds); foreach($languageFallback as $languageID) { $body = $page->getLanguageValue($languageID, 'body'); if ($body) break; } $page->body = $body; // in your template file echo $page->body; // render field body

Your client is wrong in stating this is not relational. Tables and relationships between them is what processwire does. Just differently than your client seems to be expecting it. On the other hand I feel you did miss out on proper up front communication about the requirements of your client. It's great if you want them to move on from joomla, but moving to a different system, which doesn't work for your client is worse than an old problematic one. I'd try to get back to the drawing board and evaluate more closely what the needs of your client actually are, do some demos with processwire and see if it actually can fit or not. Maybe for as long as it's "stock" wordpress, but even then things like the guttenberg editor are unstructured data in wp. I'd not say it's a good example of an relational database structure. Even more so considering how you interact with those records within php.

I am about to create several pages via API. In another script I populate the fields per language. I found that each page generated via API, even when alternative languages are also populate, they are inactive by default. Is there an API method to set it to active? Either when creating a page, or when updating it (setting field values). (PW 2.3.2 setup)

This week we’re proud to announce the newest ProcessWire master version 3.0.164. Relative to the previous master version (3.0.148) this version adds a ton of new and useful features and fixes more than 85 issues, with more than 225 commits over a period of 7 months. There were also a lot of technical changes in the core, including some pretty significant refactoring of several classes to further optimize and improve upon our already solid core, making it that much better. I’m confident this master version is one of our best and if you are running an older version I’d encourage you to upgrade when convenient to do so—I think you will really like what this version brings! Read all about what’s new in the latest blog post: https://processwire.com/blog/posts/pw-3.0.164/

As @LostKobrakai and @Jonathan Lahijani pointed out above, ProcessWire's database indeed is relational. I must also admit that I have no idea what some fields being redundant means — field tables with no values? Fields that don't have values for a specific page? Something else? Either way this is not something you messed up. Unless you've manually modified the values in the database (or the structure, tables, etc.) the database works exactly as it was designed to work, whether or not your client comprehends how it works or why it was designed that way. Also: reusing fields is the best practice, while creating a new set of fields for each template is something I'd advice against (it's bad for performance, will make selectors less useful, etc.) It's true that in what might be the most typical form — particularly for custom-built, one-off applications — each table represents a specific content type (pages, blog_posts, users, etc.) ProcessWire's database structure was designed for custom content types, so this "typical form" doesn't exactly apply here. Instead (at the most basic level) we've got a "master" table for pages, and then a new table for each field, connected to the pages table by the pages_id column. Anyway, I believe this has been explained a number of times already, so let's leave it at that. The long story short is that this is how ProcessWire was built to work, and this part cannot be changed. Behind the scenes ProFields Table creates a single database table for each field. So far it's exactly like any other field, but the big difference is that it actually allows one to modify the structure of that table via GUI, while for most other field types the table structure is "set in stone" (defined as codified rules within a Fieldtype module). The main benefit of a ProFields Table field is that it can very efficiently hold multiple (interconnected/related) value items — or table rows. A Repeater or PageTable field does the same, but behind the scenes each Repeater or PageTable item is a Page, and each property (subfield) is a field value. Thus the Repeater (or PageTable) approach comes with a different set of constrictions and benefits. (You could reap pretty much the same benefits by developing custom per-field Fieldtypes, but that takes a lot more effort than just creating and configuring a new ProFields Table field ?) I sincerely hope that you can convince your client that managing content handled by ProcessWire directly via the database is not the right approach. I definitely get that this is a frustrating situation, both for you and your client.

ProcessWire's database structure is unusual when first looking at it... Alien in fact. I had a similar reaction in the beginning. But then as you use the system, especially if coming from other content management systems, you'll see that it's very well thought out, flexible and performant. If you compare it to WordPress which has a more traditional structure combined with the post meta table, you'll see where WordPress' approach breaks down. Menus in WP get shoved into the post and post meta table in a really hacky way... Not good. Woocommerce from what I understand now uses their own table structures as opposed to the default WP ones. Slow Woocommerce sites were a big problem. Regardless of the system, editing data directly in MySQL is a bad idea. If I had a potential client that insisted on this, it would be a huge red flag. If they want to get hands on and edit data programmatically, I'd recommend learning the basics of manipulating pages via the API which may satisfy their need.

Processwire and the whole community is AMAZING, but the only thing that I think is missing... is the part where developers start to create, sell and maintain their plugins. By creating a premium PW plugin marketplace the following scenario will probably happen: 1. @ryan will/can receive a comision on each sale. This will be a well deserved token of appreciation for all his amazing work invested to build and maintain PW. 2. Plugin creators will be constantly motivated to build, maintain compatibles and improve the quality of their plugins. 3. The developers that will pay and use the premium plugins and they will save thousands in development time. Probably their clients will be happier with smaller project fees and shorter delivery times. I’m suggesting this since I’m always looking in Craft cms plugin marketplace and I have the feeling that they have a plugin for everything. Some are silly some are amazing... i know.. But in the moment you browse it, you always have the feeling that the only thing you have to do in order to create a big project is just to put the puzzle pieces together. If PWmarketplace would be a real thing... What would be the premium plugin that you will want to buy RIGHT NOW?

Hello! I also think this would be a great thing. OctoberCMS has also a marketplace and 30% of the plugin price supports the project. Have a nice day!

@teppo, a bit off-topic but I'm curious about the use of runHooks() because I haven't seen this used before. If you are adding a custom hook method "myEvent", what's the reason to do... $this->runHooks('myEvent', ['what' => 'listening']); ...instead of... $this->myEvent('listening');

ListerPro extends the Lister class, so it's a superset of functionality of Lister, so any bugs in Lister probably also apply in ListerPro. API reference for both is here: https://processwire.com/api/ref/process-page-lister/ I've found the upgrade to ListerPro well worth it, however if you're prepared to write your own modules some of the things it provides like saved lister layouts can easily be achieved with Lister, with minimal coding. I've used ListerPro to export (to CSV), but not to import. I wonder if the issue here is that has_parent is referring to the page id field rather than the title?

https://github.com/ryancramerdesign/ImportPagesCSV for all your import needs. I have moved Drupal sites, Wordpress sites, Joomla sites. As long as you have a good export routine, this module works flawlessly for me.

@AndZyk great work. ? Only other feedback I have is that the buttons "What do I see?", "What do I hear" & "How does the hustle & bustle affect me?" don't go anywhere/show anything. My cursor changed from normal arrow to an 'edit' icon, not pointer on hover. Is this supposed to happen? I'm using Chrome on an iMac

Please check status and/ or permission $events = $pages->find("template=event, related_pages.template.name=exhibition,include=all,check_access=0"); include=hidden include=unpublished include=all Check if your template is accessible via API if it is not viewable for the current user!

Same setup here :-).

Thanks! I just posted a feature request.

Ah, the or groups selector post ? We really needed this a few years ago. Unfortunately Ryan did not manage to implement this. No hard feelings though since this is not an easy task. But I do believe it should be developed since this is a big USP over other rule builders. ProcessWire can really shine with these kind of data structures. I eventually created a Process module which created pages has a sort of multiplier field of InputfieldSelector. The client could scope the main selector and add groups by adding more selectors. - Main Selector template=foo (InputfieldSelector) |-- Selector 1 (OR) somevalue=bar (repeatable field with InputfieldSelector) |-- Selector 2 (OR) someothervalue=foobar (etc) This fields eventually resolved in: "template=foo, (somevalue=bar), (someothervalue=foobar)". I created another Process Module we rendered these selectors in a list and created urls (using the great ProcessPageListerUrls). This might feel like overkill, but the client wanted to query complex selectors.

In case you want it a little more simpler $pages->setOutputFormatting(false); $pag = $pages->find("template=basic-page"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }

Thanks! Just in case anybody else searches for similar things, here's a simple example $en = 'status' . $languages->get('en'); $us = 'status' . $languages->get('us'); $fr = 'status' . $languages->get('fr'); $pag = $pages->find("parent=1072, template='product'"); foreach($pag as $p) { $p->setOutputFormatting(false); // not sure if necessary here - I made it a habit to always include it, just in case... $p->$en = 1; $p->$fr = 1; $p->$us = 1; $p->save(); }

Without knowing or testing it must be status1015=1 (where id is the language)