Leaderboard

@fruid I don't really understand your use-case. You say your client is going to use SQL to update the database, does that mean they are going to write raw SQL queries in front of a terminal? That seems like a really inefficient way to go about content creation, especially since you have to make sure your data fits within the constraints defined in the template and field settings. Despite that, you can still do that, you just have to add a couple of JOINs and be careful with your WHERE clauses. Each field table comes with a foreign key corresponding to the page ID. If your client is really some kind of SQL wizard who prefers the power of raw SQL for data migration over the limited interfaces puny mortals have to use, what's stopping them? Or do you mean "the client is going to log into phpMyAdmin / Adminer / MySQL Workbench / ... and insert data through that interface"? In that case, you're not really using SQL anyway, you're just using an interface that's closer to the database, that *may* be slightly more efficient to use for batch creation / updates if you really know what you're doing. If that's what your client wants – well, that's an interface you can build for them! Something like a batch update module that lists pages and allows you to edit them inline. In fact, such a module exists already: Lister Pro comes with inline editing for multiple fields at once. This gives you a convenient interface to update many pages at once and still stay within one backend and have all the input / constraint validation apply to your edits. Best of both worlds ? By the way, if you've ever tried to manually find something in a Drupal 8 database, you will like ProcessWire's database structure MUCH more ...

The hosting company 20i here in the UK have added ProcessWire as a 1-click install. This is a really good company, they recently advertised on FileZilla installs (may still do). Here is the announcement: https://mailchi.mp/20i/august-news-for-20i-resellers

Each field may belong to more than one template, and each template has a different set of fields. Current structure works well with that concept, makes it possible to connect (or disconnect) fields with/from templates with ease, makes it unlikely for a single table to grow to giant proportions (thus making all queries against it slower), and also allows fetching/searching/saving the exact data that ProcessWire needs to fulfil a specific request. So yes — there are advantages to current structure. It's also a very fundamental part of ProcessWire, so changing it is not possible without major changes to the core ? It has been. If you'd like to read a bit more on it, I'd suggest doing a google search for something like "processwire database structure". You'll find a lot of existing content on this topic ? Your point of view is not unheard of for newcomers but trust me, there are valid reasons why the database architecture is what it is. Much of it is due to the fact that ProcessWire — unlike some competing platforms, I might add — was designed with custom data structures (custom fields) in mind from the ground-up. Some other systems (WordPress, for one) have a much simpler database structure, but that's because they weren't originally intended for the same kind of use as ProcessWire. In the context of ProcessWire this would be a bad idea: First of all the Admin is a ready-to-use tool for managing content, and I highly doubt that anyone will really have easier time managing the content with raw SQL. It can be fun and/or if you've had to do that a lot in the past you may be used to it, but still: ask them to give the Admin a try and I bet that this idea will go away in no time. If you manually update the rows in the database, most of what ProcessWire's fields do will be completely skipped. This includes validation, filtering, and sanitization; things that are there to help you build sites with valid and well formed data. Without these features you will run into trouble eventually, it's just a matter of time. ProcessWire does internal cleanups and such using hooks, and those will not get triggered if you update the data manually in the database. This means that you'll likely be left with broken data, missing pieces here and there, and so on. Some fields (take Repeaters for an example) will also be very difficult to update manually via database. Finally, while we're on the topic of hooks: they are a major feature in ProcessWire, used by both core and third party (module) code — and, once you get used to it, probably your own code as well — and again if you don't go through the "official channels" (API or Admin) you'll loose this benefit altogether.

That was the way they did it in other CMSs I used in former times - before I luckily found ProcessWire! It was like a breeze of fresh air after a long stuffy time... The dilemma you are in is to incline to habits you are familiar with. Try to understand the way PW works, and you will soon be convinced. (And as a next step: Try to convince the client...) All the best!

No, that's a common misconception. There's no security benefit at all (it can be bypassed super easily), but comes with multiple downsides (worse UX, higher chance of typos). It may even decrease security because it discourages the usage of password managers. See security.SE, NCSE and web.dev for reference. By the way that's only slightly related to this issue. The profile page does allow passwords to be pasted; but the inputs for the new password are only activated after the old password field has been typed into, and that event handler only listens for input events, not paste events.

@MoritzLost "Don't Panic Ipsum" is pretty cool. Nice work!

This is not the whole picture. Simple fields might only have a single `data` column, but complex ones might have many more. Also multi-language support does work by adding `data_{lang}` columns to those field tables. Though I can see the argument for having template (or more correctly fieldgroup) based tables, where columns of fields would be merged into an single table.

It happens to all of us ? This is actually why I dislike the use of the magic methods like __call, because they make tiny mistakes like this harder to spot ... without the magic, this would just result in a clear, easy to fix error message, but with it it's way harder to figure out what's going on.

Not quite sure what's causing the recursion error, but your method is marked private, which means it can't be called from outsite. Because your page class extends Page which extends Wire which comes with a magic __call method that will be invoked in this case. That method tries to figure out what you're trying to do, since it's supposed to provide easy access to properties and methods of all Wire extending objects. The error call stack indicates there's something going wrong there. Making your getSummary method public should fix the issue!

@cb2004 - if that works, great - I didn't think it would work to set something in ready.php and use it in config.php PS - you can simplify the $subMembers bit to: $subMembers = wire('pages')->get(1302)->children->each('id'); or even better because it won't load the pages, just their IDs: $subMembers = wire('pages')->findIDs('parent=1302');

@ryan In the spirit of closing up Github issues, could you take a look at issue #1133? Changing passwords on the profile page does not work if the old password is pasted instead of typed in manually. Edge-case, admittedly, but when a client stumbles upon this it's pretty disruptive. As far as I can tell it's just a jQuery event that needs to listen to paste events as well as input events, so it should be a one-line fix. Though of course I don't know the code base so well, so I might be mistaken ? Same for issue #1111 about titles getting cut off in the page tree. Thanks!

Is it possible to control Processwire hook priorities, other than what the module devs agree on? For example, I have installed Redirects 404Logger 404Search The behaviour I want is: Redirect if possible, else Log page not found, and Do 404 search The behaviour I have is Log page not found, and Redirect if possible, else Do 404 search If I could lower the priority of 404Logger, then I guess this would work as I need it to. I imagine I can modify the module, but I'd want this to be update survivable. Cheers, Paul

The hook priority did the trick! Thanks @adrian! I have found the post about the module autoload order. But it did not help me as you predicted (still not quite sure why, though).

Am I right in thinking that multiple hooks that are added for the same event can be prioritised by doing something like this... $session->addHookAfter( 'login', $this, 'myLoginHook', array('priority'=>xyz) ); Where xyz is the relative priority for the hook and the lower the value, the earlier it will be called as the hooks are executed?

As of now I am a user of this feature too) Thanks to @adrian's link. I did need it to fix this issue. If you read through the linked thread you'll see that I confused module autoload order with hook order. Actually I thought that the module, that gets loaded first, would add the hook first (or last). So the autoload order would affect hook order. I did play with autoload order of the modules without success. Why is it not it the case? If it was, there could a chance to add an option to override module autoload order in admin, making it adjustable without code hacks , solving this question.

Correct - that is why I was saying that I don't think it's an ideal setup.

You're confusing module load priority with hook priority. The link above is to set hook priority. The module load priority was introduced quite recently and is what Tracy uses to make sure it is loaded before other modules, but what you want to adjust is the hook priority.

Here's the thread that explains it:

Hi @Ivan Gretsky - I think you are probably on track with it being a hook priority issue. Unfortunately PW's approach to this is not very convenient IMO - I think it would be better if developers could have the option to set the priority in each PW install, as needed because otherwise the module developer has to set it without knowing what other modules might be installed on the site that also hook into the same methods. I think for now you might have to adjust the priority yourself in both modules to ensure that PageEditPerUser overrides ARB as needed. Please also note this issue (https://github.com/ryancramerdesign/PageEditPerUser/issues/4) in Ryan's module - not sure how much it affects its intended functionality, but worth keeping an eye on, or fixing yourself. Sorry, I don't have time to investigate properly at the moment but if you have any specific requested changes to the module to make it work as you need, just let me know.

Hi @fruid, I understand your concerns. The db structure can look quite complex, especially if you are used to working with db tables and SQL select ... from ... etc; Teppo explained the reason for this structure. The great thing about this structure is that you get an abstraction layer that makes all the PW awesomeness possible. It transforms all the custom fields and data in the database into PHP page objects that can be used for easy and effortless markup generation. I'm talking about the great pw api ? echo $page->title; echo $page->headline; echo $page->image->size(200,200)->url; Display all that in multiple languages? Same code ? I think that's really genius! Are there downsides of this approach? Yes, as always. For example it is not easy for PW to do a "SELECT * FROM table_xy" to get a list of thousands of rows of data. That's because the magic of transforming the complex db structure into an easy to understand and use API has some costs. It needs to load all rows of data into memory and therefore this get's slow when working with lots of data. PW handles this by applying pagination wherever possible, so that it only loads chunks of data and stays fast. But still there might be situations where you simply need a good old "SELECT * FROM ..." and "foreach($pages as $page) $rows[] = [$page->title, $page->headline, ...]" is no option. That was quite a long introduction and explanation why I built RockFinder3 ? So at least the PULL part of your request is already doable ? What about the PUSH part (meaning updating data in the DB, doing "UPDATE ... , INSERT INTO ...")? First, you can still use native SQL commands on PW, it's quite easy: $result = $this->database->query("SELECT * FROM pages LIMIT 5"); var_dump($result->fetchAll(\PDO::FETCH_OBJ)); The problem is, that updating data can get quite complex because you need to update several tables, several fields, several languages... That's why such operations should really be done via API. That's of course a totally different approach if you are used to working with SQL commands, but it is the best option in 99,5% of the cases. There's a topic about that where I showed my findings: For the remaining 0,5%: You see, it can be quite easy. Is it a good idea? 99,5% no, because you don't get all the security features of PW that ensure that data is sanitized before storage etc. And you don't get the power of hooks. Updating pages via API will still trigger saveReady() and saved() hooks while direct SQL updates will not. Hope that helps ?

Right, thanks, I left a session message in there. I pushed a patch at version 0.7.1. While it propagates to the module directory, removing line 119 of DashboardPanelCollection.module should work as well.

In preparation for the next master version, this week no new features were added, but just like last week, more than a dozen issue reports were resolved. Having focused largely on fixing various issues over the last month, I feel pretty confident that the current dev branch is significantly more solid than the 3.0.148 master version. It adds and improves a whole lot, and also fixes a lot. And to the best of my knowledge, there aren’t any new issues between 3.0.146 and 3.0.164 that haven’t already been fixed. Basically, I don’t think it makes any sense to keep all these updates exclusive to the dev branch any longer, so have merged it to master, today. Consider it a soft launch, as I haven’t made it an official tagged version yet. Maybe I’m shy, but wanted to wait till Monday before Git tagging it and making it official. The master branch has a different audience than the dev branch, and so there’s always that possibility that some new issue will appear that hasn’t on the dev branch, and wouldn’t have. So we’ll let it marinate on the master branch for the weekend before broadcasting it very far. By this time next week, I should have a blog post ready that covers all that’s new in this version, which is 226 commits ahead of the previous master (3.0.148), so there’s a lot to cover. I want to thank you all that have been helping to identify and report issues on GitHub as they come up. Having covered a lot of issue reports over the last month, I can see a lot of effort goes into preparing many of the reports. Your work is appreciated. This month I focused primarily on the reports that I thought were likely to make the most difference to the most people. I also focused on issues that I thought could be accommodated without introducing potentially new issues or new code to test. Of course, not every report could be covered, and there’s always more to do, so I’ll be getting back to it on the dev branch here soon. In addition, I’ve held off on some new things I’ve wanted to add for awhile (a feature freeze of sorts) in preparation for an end-of-month master version. I’m looking forward to outlining all that’s new in next week’s blog post. Until then, thanks for reading and if you get a chance to test out the new 3.0.164 version, please do and let me know how it goes (both master and dev branches are identical right now). I hope you have a great weekend!

I would second MoritzLost's viewpoint here. Most template engines auto-escape output — so as soon as you use Twig or Latte for your views, it's best to disable the entity formatter for all fields and let the template engine handle it.

Your topic says 'pipe selector not working' There are two different uses of pipe selectors in your sample code. template=article|blog_post|book - OR selectors: matching one value or another (docs) title|body|author*=$q - OR selectors, matching one field or another (docs) Which one isn't working? Are you not getting any results or is it returning unwanted results? Are you sure it is not the AND selectors (docs) that are 'interfering'? Perhaps you want OR:groups (docs)?

Thanks @Ivan Gretsky and @BillH! I'm gonna use the first method with the templates. I see the interest about tags, but for my project, I have to use the templates

There's now a free and open source version similar to sizzy available: https://responsively.app/

The idea from @Ivan Gretsky of using template tags (which are on the Advanced tab of Edit Template) seems like a really good one. An approach to searching for tags on templates is here: Another possibility would be to prefix each relevant template name (e.g. "prefix-templatename") and then find using the "starts with" operator: $foundPages = $pages->find("template^=prefix"); But I think the tags approach would probably be better – more flexible, and organises things nicely on the Templates page in the admin.

There is no easy way I know of to do exactly what you're asking for. But as far as I understand the actual need is to find pages with selected templates. If you do not need to select the templates to be used in selector in admin, you should be able to hard-code the selector like this (see here for explanation): <?php $childChildren = $pages->find("template=template-a|template-b|template-c, sort=sort"); If you need to be able to select the templates in admin, you could add this module to some page, and then use it's value in a selector. Hope the module still works in current version of PW. There is an option to tag fields in admin and then use the tag instead of a list of fields in selectors. If the same thing worked for templates, that could be a good way to solve this task. But I did not find any docs on that, so you just might want give it a try first, and then fallback to the module if it's not possible.

Thanks, @ryan! Sometimes I think that ProcessWire is so mature and feature rich that only fixing the issues at hand can make it stand out even more than adding the new stuff (until the the stuff is added and I start thinking that I could not live without the features just added))) Thank you so much for keeping the right balance.

MultiValue Textformatter for ProcessWire Set flexible data structures in "key = value1, value2, ..." format to use as variable groups in templates. Great for general site settings, social links, menus, etc. Converts contents of textarea field "social_links" from this: @ url ::: title ::: target Facebook = https://facebook.com/mycompany ::: Follow us on Facebook ::: _blank Linkedin = https://www.linkedin.com/mycompany ::: NULL ::: _blank Email = #contact ::: Contact to an object to be used like this: echo $page->social_links->facebook->title // result: "Follow us on Facebook" echo $page->social_links->email->title // result: "Contact" Putting it together: <ul> <?php foreach($page->social_links as $item) { ?> <li> <a href="<?php echo $item->url; ?>" target="<?php echo $item->target; ?>" title="<?php echo $item->title; ?>"> <?php // name is the original key echo $item->name; ?> </a> </li> <?php } ?> </ul> Syntax: @ header1 ::: header2 ::: header3 Key = value ::: value ::: value [ ::: ...] Another key = value ::: value [...] More info: Modules directory GitHub Feedbacks and suggestions are welcome.

Note that legislation may differ from country to country. For an example here in Finland one apparently still has to document the cookies, even though "necessary" ones don't require opt-in (or opt-out). IANAL etc. but that seems to be the common consensus anyway ? Here's a rough translation of the descriptions we've been using: wires ProcessWire session identifier. First-party session cookie, expires when the browser is closed. wires_challenge ProcessWire session cookie used to verify the validity of a session. First-party persistent cookie, expires after 30 days.

@SamC it's really as simple as that: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks Update 2022: $wire->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments('page'); bd('page saved'); bd($event, 'event'); bd($event->object, 'event->object'); bd($event->arguments(), 'event->arguments'); }); in the beginning it can be a little confusing when to use event->object, event->arguments and event->return but with the help of tracy you can quickly bring light into the dark: add the code above to the tracy console, set the radio on the right to load it on "ready" (same as placing the code in the site/ready.php file) and save any page: $event->arguments('page') is the same as using $event->arguments(0) that you will see very often and in the tracy dump you see that 0 is simply the key for the first argument in that hookevent. you can also collapse the "data" property of the hookevent and you would see the same: You can also use your IDE to quickly find what the HookEvent is returning/containing in which hook. Let's take the common saveReady hook as an example: We know that the hook is attached as Pages::saveReady (eg because we have read that somewhere) That means that the hook is part of the "Pages" class, which is located at "/wire/core/Pages.php" - that's easy to find out using CTRL+P in VSCode: Searching for "___saveReady" lets us find the corresponding method: Now we see, that we have ONE "arguments", being Page $page - this means $event->arguments(0) would return the page being ready for saving $event->object would be the class, here "Pages" $event->return is the return value of that method, here $data (line 1739) Edit: There's some additional explanations in this post: https://processwire.com/talk/topic/27248-pagestrashtemplatefoo-vs-pagestemplatefootrash/?do=findComment&comment=224659 #search afraid of hooks

For simple json outputs, you can use WireArray::explode and json_encode() or wireEncodeJSON() methods https://processwire.com/api/ref/wire-array/explode/ $myPages = $pages->find('template=basic-page'); // extract required fields into plain array $data = $myPages->explode(['title', 'created']); echo wireEncodeJSON($data);

Hi everyone, Some critical updates this morning: 1) The module stopped doing anything in recent versions of PW 3 - I don't exactly when, but this is now fixed. 2) I also added support for restricting the new Pages > Tree dropdown menu that was added in 3.0.55 Please let me know if you find any problems with these changes or if you find any other situations where the module is no longer working. Given the rapid development of new ways to access the page tree that are being added to PW, I strongly recommend thoroughly testing your site if this module is protecting critical info from certain users. Hopefully everything is already taken care of for the current PW dev version, but with the UiKit admin theme, there could be possible breaks. Thanks for testing and letting me know!

Actually I hadn't noticed that - thanks for pointing it out. Sorry it's taken so long to get to, but the latest version of the module now has a new config setting to optionally exclude pages outside the restricted branch from the search results of pages. Please test and let me know if you find any problems.

Just thought you guys might like to know that the priority setting just got another user Needed to solve the conflict between RedirectIds and 404Search modules. Thanks again Ryan for thinking of everything!

Ok, an update. To get two of my modules to work well together I do need this functionality. I basically want the 2-factor login module to get first crack at the hook before the login alarm gets to log/email the users. I set the priority in the 2-factor module to 10 and in the alarm module to 2000 (just to be sure) however on adding a die(__CLASS__) to both hook handler routines I could see that the alarm module was getting called first. An unexpected result, but I've now found out why. It turns out that I was hooking the login event in slightly different ways and this does seem to effect the order the routines get called in. In the 2-factor module I was doing this... $this->addHookAfter( "Session::login", $this, 'my2FactorHook', array('priority'=>10)); Whilst in the alarm module I was adding the hook differently... $this->session->addHookAfter( "login", $this, 'myAlarmHook', array('priority'=>2000)); Switching the 2-factor init() routine over to using $this->session->addHookAfter('login'...) has everything called in the right order.

That's correct. At least, that was the intention. It's one of those things I thought would come in more handy than it has… I'm not aware of it ever being used. So I think the only time it has even been tested is when I originally coded it in there (at which time it was working). No recent confirmation of current functionality though. A quick glance in the code seems to indicate that it should work as intended, though please let me know if you find otherwise. Default priority level is 100 (that's what gets assigned when none assigned).