Leaderboard

As someone who has spent considerable time dealing with similar issues, submitting error reports and PRs, etc. in the context of WordPress plugins, I can say that it's simply a general issue with dependencies. Popularity of the CMS matters very little, if at all. Relative popularity of the module/plugin matters more, though even that is not a 100% guarantee. You can avoid some of this by only using the dependencies you truly require, and choosing the ones to use carefully: see if they are actively maintained, whether that is by regular code updates or via the support forum. Only using the dependencies I truly require, and choosing the ones to use carefully ? There's no silver bullet here. If the module author is still active you can submit error reports via support forum and/or GitHub. If the author is no longer active, someone (including you) could fork the module and make fixes there, but unless new maintainer is going to really commit into maintaining the module, it's not a good long term solution. For modules that are no longer actively maintained, my recommendation would be to move on — find something else that gets the job done. Or better yet, don't use a module. Again, you should only use the modules that you truly need. Alternatives for the modules you've mentioned: Instead of MarkupSEO you could look into Seo Maestro, but since the author (Wanze) has stated that they are no longer actively involved with ProcessWire, it's questionable whether this is a good long term solution either. We use Markup Metadata, which does at least some of the same tasks; it's also less involved/opinionated, which means that it's easier to maintain. Instead of AllInOneMinify I would really recommend looking into ProCache. It's not free, but if it's for a commercial purpose (or long term personal projects etc.) it is — in my opinion — well worth the cost. It also does a lot for your site's performance that AllInOneMinify won't do.

Hi everyone, Got a new feature for you today (at the request of @eydun). First some background - some of you might not even be aware that Tracy saves .html files of it's bluescreen stacktrace when an exception is thrown. The cool part about this is that these happen when Tracy is in production mode on a live site, so if you get a notification (via email or slack) that an exception was thrown, you can navigate to /site/assets/logs/tracy and load these html files in your browser and inspect the code (including values passed to functions etc). This can make debugging much easier because you don't need to try to replicate the error again. The new feature today makes viewing these much easier with a dedicated panel listing all available exception files. Simply click on one to have it display as it would if the exception was thrown while you were interacting with the site. The icon turns red when there are new exception files since your last visit and it shows which ones are new. The clear button will remove the bluescreen so you can return to your site without needing to reload the page. The Validator panel also had a revamp. It now uses https://validator.w3.org/nu/ because https://html5.validator.nu/ was no longer working and I have updated the CSS to support their new output DOM. For those of you who don't know, the key value to the Validator panel is for local dev sites where you don't have a publicly accessible URL to use - this sends the HTML of the page directly. Also included are some PHP 8.2 deprecation fixes.

Currently, the site I mostly work on is running ProcessWire 3.0.213 and PHP 8.0.x with 62 third party modules. I do not have a single issue which is worth mentioning, so I'd say this is certainly a "Peace-of-Mind Setup". Note that around ProcessWire 3.0.214 and ProcessWire 3.0.215 Ryan has started some heavy refactoring in the core so I would not call current dev versions "Peace-of-Mind" even thought he has fixed a lot of newly introduced bugs since then.

The images field value will be a Pageimages object. So when you do... $page_add->field->add() ...this is Pageimages::add(), and according to the documentation for that method it accepts either a Pageimage object or a path to an image file. You can't supply a Pageimages object to Pageimages::add(). So the relevant part of your code would need to be: foreach($page->field as $pageimage) { $page_add->field->add($pageimage); }

Future-Proof involves a bit of work on your side. Future proof just means, it could and will probably be a solid setup in the future, either with your knowledge or changes brought in, or by PW/Ryan/Module Devs. See below, please. If you are not THAT into PW or PHP... future proof or all-in/DEV setups might not work for you. You chose to use an experimental* setup of PW/PHP. * some kind of non-official setup right now (2023-07-05) The combo you chose is somewhat in-between everything right now. IMHO. I had quite a lot of issues with that combo and therefore moved to my Peace-of-Mind of setup in most cases. [Disclaimer] I AM NOT A PROGRAMMER, or even a DEV - since 2014 I just use and work with ProcessWire. And it works for me. I know almost nothing about PHP, besides echo/foreach/if/else and similar. And some details about PHP in general. I do concepts most of the time, sometimes frontends (nowadays), and in the majority SEO, Marketing, and such. So... yes... you still get those issues for whatever reason in some setups. That's why I mentioned my personal Peace-of-Mind setup above. (as it totally works for me without any issues - and I am not an example for anything in those regards) As @bernhardmentioned... contact that module dev and let them know there might be something wrong. A PR/issue report is probably the best way to communicate that, AFTER contacting that DEV directly in one way or another. PRs with a solution at hand... always a great way to contribute. SO... even though you got errors/warnings ... you helped to find issues to make PW more FUTURE PROOF and maybe even DEV setups. That's awesome. (as mentioned in some other thread, I can't find right now: PW and PHP are moving quite fast right now... issues are a thing, but the outcome will be worth it)

You can try my fork of aiom https://github.com/matjazpotocnik/ProcessWire-AIOM-All-In-One-Minify

Hi, There's not enough information to talk about the issue. It seems the provider changed its API, asking for a cookie that you don't provide. You should check if the API works outside of the form and ProcessWire.

Thanks very much for the insight, everyone. Keep your thoughts coming, as I'm going to take the plunge over the next couple of days.

A deprecation warning is nothing bad. It just tells you that the setup might cause problems in future versions of PHP but it's totally fine with the version that you are currently using. Not more, not less. So I think having a recent version of PHP with some deprecation warnings is preferable to having an outdated version of PHP without any warnings.

Thank you @Robin S . Thats it. Umpf, so obious... Interestingly i did that in the first place. But this was before i realized i have to save the new page before adding images. As i got no results at that time, i tried other solutions. And forgot to test this again after i applied the first $page_add->save(); .

Just added a couple of key fixes to the Exceptions panel - please update your copies and do a hard reload. Also, please note that this panel is now loaded by default (frontend and backend) on new Tracy installs and I would recommend making this change on all existing installs as well.

Hi @Roope, can we have a module update with the fix? Ta.

Hey Teppo! Thanks for your detailed answer! Less is more, right? ? I will definitely try out the ProCache module. In the future I will try to reduce the number of modules used.

Thanks @szabesz. I'll stick with 8.0 for the production environment for now.

I have tested the pull request in the meantime and it works. ? I am now using the module with pull request, but it would be nice if the module author could merge it.

I guess @wbmnfktr you know that, but I want to mention that PHP7.4 is end of life since 2022 and we have PHP8.1 since 2021, so while I agree on the basic concept of using newer versions for less critical projects and older ones for others I'd vote for using 8.1 for the "peace-of-mind" setup. I know being up to date with the PHP version not the only thing that counts, but I think it's good to stay at least with the latest supported version and we should encourage everybody to do so. It's really not a big deal in my opinion and if someone finds an issue in a 3rd party module that does not work with PHP8 than it's for sure better to inform the module author about that or to provide a PR than to use an outdated version of PHP. I'm on 8.1 with most of my projects and I've not had any issues for a long time. There has been a lot of deprecation warnings, but they have all been addressed and tracy debugger now also has nice color options for making those warnings/errors more comfortable for the eyes ?

@Olaf looks like there are a few issues with your code. Could you try this instead? // Get page to be copied $sourcePage = $pages->findOne(...); // Init new page $page_add = new Page(); // Set some basics $page_add->template = '<template-name>'; $page_add->parent = '</path/to/parent/>'; // Add some fields to copy $page_add->field = $sourcePage->field; ... // Save page to i get an ID $page_add->save(); // Although not neccessary, make sure we are working with array format $page_add->of(false); // Trying to add/copy the images to the new page $page_add->field->add($sourcePage->field); // For the sake of it, save page again $page_add->save();

@olafgleba As I understand it, you've got pages that live at /members/blog/<name> and you want them to be accessible at /blog/<name>. First thing is to make it so that the blog post pages ->url property reflects the URL you want them to use. You can do this with a hook in /site/init.php: $wire->addHookAfter('Page::path', function($event) { $path = $event->return; if(strpos($path, '/members/blog/') !== 0) return; $event->return = str_replace('/members/', '/', $path); }); Next, you want to make it so that ProcessWire will deliver those blog post pages at the /blog/<name> URL. You can do this either by enabling and handling URL segments on a /blog/ page, or you can use a URL/path hook, again in /site/init.php. I'm going to assume there is no /blog/ page, so a URL/path hook may be the best bet: $wire->addHook('/blog/{name}', function($event) { $name = $event->arguments('name'); $blog = wire()->pages->get("/members/blog/$name"); return $blog->id && $blog->viewable() ? $blog : false; }); Are those /members/blog/ pages are access protected from public users? If so, the above hook is not going to let them through because of the $blog->viewable() condition at the end. You could remove that, or better yet, replace it with a different condition: if($blog->isUnpublished()) return false; return $blog->id && $blog->template->name === 'blog-post' ? $blog : false; I can't remember at the moment if ProcessWire does another access control check on the returned page ($blog). So if you find it doesn't work returning the $blog page, try having it return $blog->render() instead.

Hi @a-ok, i solved this with this code: $news = $page->children("limit=5"); $pager = $modules->get('MarkupPagerNav'); // this is required in order for getUrl to work // see https://processwire.com/api/ref/markup-pager-nav/get-u-r-l/ $pager->render($news); $paginationMarkup = ''; if ($news->hasPrevPagination() || $news->hasNextPagination()) { $paginationMarkup .= '<ul>'; if ($news->hasPrevPagination()) { $paginationMarkup .= "<li><a href='{$pager->getUrl($pager->pageNum - 1)}'>prev</a></li>"; } if ($news->hasNextPagination()) { $paginationMarkup .= "<li><a href='{$pager->getUrl($pager->pageNum + 1)}'>next</a></li>"; } $paginationMarkup .= '</ul>'; } echo $paginationMarkup;