Search the Community

If you want, you can filter them out and focus more on your essentials. But first things first. There is a whole list of different PHP errors, warnings and hints (notices). The one we are interested in is E_DEPRECATED. These messages indicate that a used PHP function somewhere in the code is no longer supported in a future, i.e. higher PHP version, not the actual used one. Example: The days (February 2022) I have changed my developer machine to use the latest PHP version 8.1.2. The last PHP 7.4+ is still supported for 9 months from today on, PHP 8.0 still for 1 year + 9months, PHP 8.1 for 2 years+ 9 months, and all other PHP 8+ versions each plus one more year. So the point is clear now, right? It will be year(s) before PHP 9 is on the schedule. ? Currently in v8.1.2, depending on what code I run, I get notices that certain PHP functions will no longer be available starting with PHP 9. (PHP 9! see above). So currently these functions are safe and supported functions, as in past versions as well as in all further PHP 8+ versions(!). No matter how many additional PHP 8+ versions there will be. ProcessWire by default allows us to suppress ALL output, or show ALL output, by the boolean configuration variable "$config->debug". This is good and right, because on a production site you should always suppress all those outputs. On a developer machine it usually shouldn't bother you if there are also E_DEPRECATED hints included. But if it does, you can filter them out as follows, for example. In your site/config.php you can define a own error handler function and load / bind it on your developer machine only. As a proof of concept or simple example, I added the following function to my site/config.php /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { if(!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if(!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ With the following call, also located in my developer machines site/config.php file, I bind it to all raising E_DEPRECATED warnings ONLY! So we are sure and free from all other types of errors, warnings, hints, etc. // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); (read more on php.net) Now you will not see any of the deprecated notices any more, cluttering your screen. Neither in the front end nor in the backend. But they are all collected in our bag. ? A simple loop in the site/templates/admin.php, before the controller.php is called, can display any of it, maybe to the superusers only, for example: <?php namespace ProcessWire; // IF WE HAVE CACHED PHP DEPRECATION WARNINGS, SHOW THEM IN THE ADMIN, FOR SUPERUSERS ONLY if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG']) && $user->isSuperuser()) { foreach($GLOBALS['DEPRECATION_WARNINGS_BAG'] as $deprecatedMessageItem) { $deprecatedMessageItemMSG = "PHP DEPRECATED (v". PHP_VERSION .") = \n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[0]} : [{$deprecatedMessageItem[1]}]\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[2]}"; $this->message($deprecatedMessageItemMSG); } } require($config->paths->adminTemplates . 'controller.php'); If you want to show them on the front end to, it belongs to how you have organized your output strategy. I use a delayed output with _init.php and _main.php, where I have a special function for adding all kind of debug messages, that gets displayed on the end of the site, after the footer. Simply adding the whole collected array is enough for my information: if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { mvdr(['DEPRECATED ('. PHP_VERSION .')' => $GLOBALS['DEPRECATION_WARNINGS_BAG']]); // add it to the debug output region var } The outputs in admin then may look like this Or the very basic info for me on front end

Hi there, I'm a newbie and I'm trying to learn more about Processwire so I've setup XDebug + PHPStorm to get some real time debugging happening. I've noticed that no matter where i put a breakpoint in any of my php modules, it seems to return the following error. Error: __debuginfo() must return an array (line 55 of /Users/FrancisChung/site/Test/templates/head.inc) This error message was shown because you are logged in as a Superuser. Error has been logged. I was wondering if fellow Processwire users have a similar setup, and was successful in getting debugging going. I've also read this forum post: https://processwire.com/talk/topic/1611-yes-debugging-templates-and-core-code-works/ I'm also aware there's an issue with XDebug and Processwire: https://github.com/ryancramerdesign/ProcessWire/issues/1316

Hi everyone, [edit: do not loose your time reading this post, I solved it by disabling cache in the Pages2Pdf module... sorry ?] I do not know if I should post on the Pages2Pdf thread or here. Mods, feel free to move the post. Since three days I am scratching my head to understand a weird thing happening with $session and $config->debug used in conjunction with Pages2Pdf module. For information, I tested it on a fresh install of ProcessWire 3.0.96 with PHP-7.0.28 and Pages2Pdf-1.1.7 (domain: http://session.sites.sek/). I will try to explain what is going on. What I am trying to achieve : In a template, I need to set some sessions variables which are then echo'd in the PDF document. (on the test installation, the basic-page template (page /about/?pages2pdf) serve the PDF, the home and sitemap template set the session variable.) The problem : From the template sitemap, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Sitemap template'); From the template home, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Home template'); Then in the PDF default template, I echo the session variable: <p>Session: <?= $session->getFor('pdf', 'myvar'); ?></p> Now I turn ON debug mode ($config->debug = true) : Then I navigate to "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Now I want my PDF document, so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and I get my PDF document with the right session var : "Session set from Sitemap template" For the moment, nothing special happen. Everything work great. We are in debug mode. Now I turn OFF debug mode ($config->debug = false) : Then I navigate to "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Then I navigate back to "http://session.sites.sek/home/" and the session variable "myvar" is set back to "Session set from Home template". Now I want my PDF document - as expected, the "myvar" should be set to "Session set from Home template" - so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and here the problem happen. Instead of echoing "Session set from Home template" in the PDF document, the phrase "Session set from sitemap" is echo'd (the last value recorded before switching from debug ON). I made two small screencasts to show the issue : DEBUG ON (Everything is OK) DEBUG OFF I am missing something ? EDIT: YES, you are dumb!

Hi everyone, [edit: do not loose your time reading this post, I solved it by disabling cache in the Pages2Pdf module... sorry ?] I do not know if I should post on the Pages2Pdf thread or here. Mods, feel free to move the post. Since three days I am scratching my head to understand a weird thing happening with $session and $config->debug used in conjunction with Pages2Pdf module. For information, I tested it on a fresh install of ProcessWire 3.0.96 with PHP-7.0.28 and Pages2Pdf-1.1.7 (domain: http://session.sites.sek/). I will try to explain what is going on. What I am trying to achieve : In a template, I need to set some sessions variables which are then echo'd in the PDF document. (on the test installation, the basic-page template (page /about/?pages2pdf) serve the PDF, the home and sitemap template set the session variable.) The problem : From the template sitemap, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Sitemap template'); From the template home, I set a variable: $session->setFor('pdf', 'myvar', 'Session set from Home template'); Then in the PDF default template, I echo the session variable: <p>Session: <?= $session->getFor('pdf', 'myvar'); ?></p> Now I turn ON debug mode ($config->debug = true) : Then I navigate to "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Now I want my PDF document, so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and I get my PDF document with the right session var : "Session set from Sitemap template" For the moment, nothing special happen. Everything work great. We are in debug mode. Now I turn OFF debug mode ($config->debug = false) : Then I navigate to "http://session.sites.sek/home/" and the session variable "myvar" is set to "Session set from Home template". Then I navigate to "http://session.sites.sek/sitemap/" and the session variable "myvar" is set to "Session set from Sitemap template". Then I navigate back to "http://session.sites.sek/home/" and the session variable "myvar" is set back to "Session set from Home template". Now I want my PDF document - as expected, the "myvar" should be set to "Session set from Home template" - so I navigate to "http://session.sites.sek/about/?pages2pdf=1" and here the problem happen. Instead of echoing "Session set from Home template" in the PDF document, the phrase "Session set from sitemap" is echo'd (the last value recorded before switching from debug ON). I made two small screencasts to show the issue : DEBUG ON (Everything is OK) DEBUG OFF I am missing something ? EDIT: YES, you are dumb! Why it is working with debug mode ON and not vice-versa ? Is there someone who already spotted this strange behavior ? Is there a PHP settings which should be modified ? ==================================================== Edit: I needed to post just to figure myself that Pages2Pdf cache the document when $config->debug is false. ???

Usually I write modules just for me and my projects because they are more or less individual. Mail Debugger is the first module which might be interested for someone else as well. https://modules.processwire.com/modules/mail-debugger/ Basically it covers two use cases: 1) Log outgoing emails 2) In debug mode mails are send to a specified email address instead of the original recipient(s) I checked the compatibility for PW 3+ because unfortunately I don't have any other version for testing currently. Feel free to drop me a comment if the module works also for older PW versions.

There is no reason for this to have happened, I was not working on anything related to this: I deleted the site cache and it's still happening. The whole site is broken. This is what happened last time and I had to rebuild. Now I'll have to again. I really need to use version control this time for sure. But nonetheless, I wasn't even working on these files.

Hi, here is a very useful tool that check your images in websites against responsiveness: https://github.com/ausi/respimagelint

Does anybody know why I am unable to debug images? I only see the field name, but not the array with the list of images, I tried xdebug and tracy debugger... This is my code: var_dumb($page->fields) or dumbAll($page->fields). This is what I see, note that I have several images (array) in this page: If I try foreach on the fieldgroup and output the fieldname I can get the image url... P.S. a little bit off topic...but is there a way to just get the data/values of the fields? I don't really care about all the other fields like hooks, wire, notices, etc etc...

Hi all One of my sites (running PW since 2014, currently v. 2.5.3) had problems with crashed tables. Last week the body field and and image field crashed – noteworthy the latter crashed in a separate DB in my working copy. A couple hours ago another field table crashed (production system again). Funnily, today's table fixed itself. The site has nearly 20,000 pages, about 100 users a day and is installed on a managed server. Unless the logs in sites/assets/logs/errors.txt I have no idea how to research the problem. The hosting company says 'system is fine' and 'mostly it's cased by the CMS'. I have seen others here having that problem, but unless fixing it immediately with repair table there wasn't much info to see what is wrong. Perhaps you guys have some tips how to debug that kind of problem. I even don't know if it is possible to fix this on my own … if it's a problem with the filesystem for example. Any ideas? My code or system failure?

Having milliseconds retrieval time in the PDO querylog would shed light on an otherwise dark corner of performance monitoring. When the MySQL adapter transitioned to PDO, the query log timings were omitted from the log output. The older MySQLi logs included milliseconds elapsed, which was helpful in surfacing retrieval bottlenecks. Attempts to manually profile PDO queries often run up against a profiling_history_size of 100, a limit imposed by MySQL itself. That is to say that getting a complete list of timings over the course of serving a page isn't always easy. Having these added back to the querylog (if possible) would be extremely helpful.

Hi there, I have recently transferred my Processwire to a different host. I have created a database and imported to the new host server and have transferred all the files Processwire. I have also created a database user and updated the config.php file with the necessary information and I am getting the following error in debug mode: Fatal error: Exception: DB connect error 1045 - Access denied for user 'admin'@'192.249.113.81' (using password: YES) (in /home/admin/public_html/wire/core/ProcessWire.php line 96) #0 /home/admin/public_html/wire/core/ProcessWire.php(45): ProcessWire->load(Object(Config)) #1 /home/admin/public_html/index.php(183): ProcessWire->__construct(Object(Config)) #2 {main} in/home/admin/public_html/index.php on line 214 This error message was shown because site is in debug mode ($config->debug = true; in /site/config.php). Error has been logged. Any clues of what is happening? Can anyone please help me? Thanks

Trying to work out what is causing an approx. 20 second when loading a page of thumbs for a product catalogue. I have debug = true without any issues. Also, I have checked the server error logs and nothing either. I have several processwire installations on this server all operating fine. Some with very similar setups. I have checked the selector with selector test module and it seems OK. Looking on chrome inspect, the problem is right at the start where the delay occurs. Once that passes, everything loads almost instantly. Also, this occurs on chrome & firefox. Oh, and I should say that no other page is affected that I am aware of. So, as I am finding this a bit frustrating, I was wondering if anyone has any tips as how to debug this? Just in case I have put the code for the page below. edit: One other thing the product_cats field is a page fieldtype. <?php require_once("inc/header.inc"); $type = $page->title; $selector = "product_cats.title=" . $type; $products = $pages->find("$selector, limit=12"); //print_r($products); $pagination = $products->renderPager(array( 'nextItemLabel' => "Next", 'previousItemLabel' => "Prev", 'listMarkup' => "<ul class='MarkupPagerNav pagination'>{out}</ul>", 'currentItemClass' => "current", 'firstItemClass' => "arrow", 'lastItemClass' => "arrow" )); ?> <div class="row firstrow lastrow"> <div class="pagination-centered"> <?=$pagination?> </div> <?php foreach($products AS $product) { $pageimage = $product->images->first(); ?> <div class="small-6 medium-4 large-4 columns" itemscope itemtype="http://schema.org/Product"> <a href="<?= $product->url ?>"><img src="<?=$pageimage->pimLoad('myPrefix')->canvas(350, 350, array(255,255,255,0))->pimSave()->url ?>" itemprop="image"></a> <div class="prod_panel panel"> <h5 itemprop="name"><?= $product->id ?> <?= $product->title ?></h5> </div> </div> <?php } ?> <div class="clearer"> </div> <div class="pagination-centered"> <?=$pagination?> </div> </div> <?php require_once("inc/footer.inc");

In case you didn't know or had forgotten, in PW you can edit /site/config.php and set $config->debug = true; to help track down errors. I've often found 'soft errors' (bad practice PHP etc (something you get if you are PHP 'lite' like I am)) that were previously hidden are displayed when this is set to true. But I also found I set it and forget that it's set then sometimes see a page load slightly slowly or with a visible 'flash' and wonder what's wrong, only later remembering I have debug left on. So now as a reminder I echo (if the setting is true) a reminder somewhere obvious such as adjacent to the homepage (or every pages's) H1. It's good to be reminded since going to a production site with it set to true is NOT recommended (API doc). This is the simple test and echo I now add: if(wire('config')->debug) echo "<span class='alert'>Flashy? Slow? Probably because of \$config->debug = true;</span>";