Leaderboard

Hello I wrote this small article https://dev.to/clsource/processwires-pros-and-cons-2o8n I would love to know if there any other considerations or ideas regarding that article. Thanks ?

Nice writeup, congratulations ?

ProcessWire 3.0.196 contains 10 minor issue fixes, but the biggest additions this week are 6 pull requests submitted from @bernhard. This most notable PR is an upgrade to AdminThemeUikit that enables greater customization of the theme's markup. If you recall, Bernhard also provided a PR last year that enables customization of the admin theme's CSS/LESS, so now he's now completed the circle and provided us with a direction for customizing the markup as well. This newest addition lets you provide your own custom render files for different parts of the admin theme by placing them in /site/templates/AdminThemeUikit/. Third party modules can also define custom render files. Furthermore, this addition adds a new hook that enables you (or your modules) to hook into and modify just about any part of the admin theme rendering. Rather than going into all the details and repeating all of the instructions here, see the new AdminThemeUikit README file "Customizing Markup" section which describes all of the different things you can modify and how to do so. You can also find all of the render files in the core AdminThemeUikit directory — any .php files beginning with an underscore are custom render files that can be overridden. While not as broad in scope, there were other useful PRs added this week as well, so be sure to see the dev branch commit log if you are interested in seeing what else was added. Thanks for reading and have a great weekend.

@MarkE, thanks for the report. Please try the updated v0.3.4.

I was able to solve the problem. After logging into the backend and getting the blank admin page I discovered a log entry inside the tracy debugger log. There was an issue in my /site/ready.php file that threw an error: PHP Warning: Cannot modify header information - headers already sent by That error was caused by some spaces behind the closing ?> Tag inside the ready.php. I am using this same ready.php file on multiple other websites and it never made me any trouble though. I find the fact weird that this error is only provoked when trying to log into the backend. Anyhow I am glad that this is solved now.

Have you looked at: https://processwire.com/talk/topic/26070-error-exception-unable-to-obtain-lock-for-session/ ? I didn't actually know about this Tracy issue. I think perhaps it's a combo between it and the SessionHandlerDB module. Tracy does now use a different approach to sessions (by default), but I'd still try disabling the SessionHandlerDB module.

Do you have an older version of Tracy Debugger installed? If yes, try to switch off Tracy or update Tracy to the latest version (4.23.25).

@bernhard I don't have numbers, but it would be interesting to benchmark sometime. I do know that I've tried to optimize the hook calls as much as possible, so I expect they should be fast. I would guess that you'd have to get the combined effect of many calls before you start seeing the difference. But it does still take significant code to make hooks happen, as the method call has to pass through a PHP __call() which then checks of there are any hook methods available to call, then it triggers any found before hook methods, calls the the original hooked method, gets the return value, then triggers any found after hooks, gets the return value again, then returns control to the original __call(), which then provides the return value to the caller. It's the minimum needed, but it's still a lot of steps. In the case of the admin theme, all the parts of it get added via include() calls to the different layout files, and that's very fast. I wanted to keep that benefit for cases where people didn't need to override anything or, didn't have hooks. That way it's still just a simple fast include(), except when you wanted to hook into it or use customize different files. It may not be something you can feel in any one request, but it would be something you could measure the combined effect of over several requests. I figure it's my responsibility to make sure PW uses as little CPU (translating to as little energy) as possible for anything it does, at least the things where I know how to. Something like the admin theme gets used by everyone that uses PW, and so little things can add up to big things when spread out over the scale of all installations. But how much difference it makes, I don't know for certain. So part if it is also about having fun and trying to be useful. @cpx3 What version did you upgrade from? Enable debug mode ($config->debug=true; in /site/config.php) and also check the log files that netcarver mentioned above. That should hopefully point to whatever the issue might be in this case. Please let us know.

I seem to have encountered another problem with repeaters. I am creating repeater matrix items in the API. Different types of such items have different fields which are linked using ConnectPageFields to fields other templates. On creating some matrix types, I am encountering the error "Call to a member function find() on null" for line 132 of ConnectPageFields (v0.3.3), which is $added = $new_value->find("id!=$old_value"); This error seems to be triggered by $new_value being null. $new_value is set on line 127 as $new_value = $page->getUnformatted($this_fname); With a bit of debugging, it is clear that the module is trying to establish a link for a $this_fname which does not exist for the particular matrix type being added in the API. I think I have resolved this by saving the new matrix item before setting its type (so that all fields are present) and then saving again after setting its type. However, I wonder if it would be better to fix it by a module update. I think that changing line 130 to if($this_is_multi && $new_value && $old_value) { has the desired effect, but have not completely tested it. Thoughts?

@cpx3 Were you able to revert to the previous installed version to restore your site's operation? Also, if you look in site/assets/logs for the latest entries in the error.txt and exceptions.txt files, you may get a better picture of what's going on - and if you are running PHP with error logging turned on you can look in the PHP logs too. The exact location of these files (and if they are even used) will depend on your php.ini file.

I'd suggest that there are very much easier ways to go about things than using multiple databases. I can think of various possible approaches, but I might go about it something like this... You might have a set up like this, with the user pages below the home page having the users' names (to keep things simple for this example): home |____user1 | |____page1 | |____page2 | |____user2 |____page1 |____page2 To work with the pages for the current user, you could get the pages thus: // Get the user name $userName = $user->name; // e.g. 'user2' // Get all pages belonging to the user $userPages = $pages->find("has_parent=/$userName"); // Get page2 belonging to the user $userPage2 = $userPages->get("name=page2") An important thing to note is that in the above example $userPages is a PW PageArray (https://processwire.com/api/ref/page-array/), and you can work with this instead of with $pages (i.e. all pages). To deal with a superuser, you might do something like this: if($user->isSuperuser()) { $workingPages = $pages; // All pages } else { $userName = $user->name; $workingPages = $pages->find("has_parent=/$userName"); // As in the previous example } I've kept things simple here to illustrate the idea, but I imagine your set-up would be a lot more complex. But I hope this helps as a starting point.

The "Multiple page selection" version of Page Auto Complete doesn't support the "Custom PHP code" option (i.e. the InputfieldPage::getSelectablePages hook). In earlier versions of PW it used to be more explicit about that. Now it just removes the "Custom PHP code" option depending on what you have selected in "Input field type". Page List Select and Page List Select Multiple also do not support the "Custom PHP code" option. If you really are returning something like that from you hook then you could change to the "Selector string" option, which will work with autocomplete.

Hey @Wanze! These aren't really issues, more general feedback, so I thought I'd post them here. I've been evaluating this module as a solution for handling metadata, and as such have finally had some time to actually dig into it's numerous features – and while I see a lot of interesting stuff here, there are a few things that could perhaps use some polishing, in my opinion ? So one thing that confused me initially was the use of word "inherit". I managed to miss the point about default values being set template level in README (which obviously was a major reason for my confusion... but to my defence: when evaluating a new module I like to do it without reading too much first, since that's how most regular users – as in clients – are going to be using it anyway), so I imagined that the values would be inherited from parent pages. (Seemed a bit weird obviously, but whatever.) Now that I've double-checked the docs and understand that those values are inherited from the template, I'm actually wondering if you might consider calling this something else – perhaps "default"? It would also be good to explain somehow (in context) what "inherit" means, and where the value is inherited from? Note: I get that anyone installing the module and having access to template settings should probably realise what this is all about, but I for one don't give clients access to template settings (I see that as the developers' territory). Thus "inherit" doesn't make much sense to them – and since it's not explained in the admin (and they're unlikely to figure out that the site is using SeoMaestro and dig out the modules README or this thread), it can indeed be quite confusing. -- Another source of confusion for me was the Sitemap feature, mainly because it didn't seem to do anything. Now, looking into the source code, I see that you're using file_put_contents() – so apparently the module expects write access to the site root? It might be a good idea to add a check to see if this really is the case. At least I assume that this was the problem – didn't see any errors, but in my case Apache or PHP never have write access to directories with executable code, so if the module did try to write in those directories, it must've failed. (Personally I like the "hook 404 page and serve fake files" approach more when it comes to things like this – it doesn't require write access, and tends to work better overall in different environments.) -- Just some initial observations – hope you don't mind poking around. You're doing great job with this module! ?