Leaderboard

Introduction to RectorPHP In the dynamic world of PHP development, code refactoring is an inevitable task, whether for code optimization or transitioning to newer PHP versions. RectorPHP stands as a vital tool, simplifying this often challenging process. So, what is RectorPHP? What is RectorPHP? RectorPHP, or Rector, is a revolutionary open-source tool created to automate the process of refactoring PHP code. Refactoring, in simple terms, refers to the modification of a software system's internal structure without changing its external behavior, ultimately leading to enhanced readability and maintainability. Built on the powerful PHP Parser library, Rector analyzes and manipulates PHP code at the abstract syntax tree (AST) level. This granular control allows for intricate adjustments, making refactoring a breeze. But Rector's capabilities don't end here. Its true strength lies in its role as an automatic code upgrade tool. RectorPHP as an Automatic Code Upgrade Tool RectorPHP's primary role is to transition PHP code from legacy standards to modern, efficient, and more secure versions. This transformation allows developers to maintain their codebase up to date, benefiting from the latest advancements in PHP development. How Can RectorPHP Upgrade Your PHP Code? RectorPHP provides a smooth and efficient roadmap to upgrade old PHP code to contemporary versions. Here's how: Installation The first step is to install Rector in your project. Given it's a composer-based project, installing is as simple as running composer require rector/rector --dev in your terminal. Configuration Next, Rector requires a configuration file (rector.php) to instruct it on what to refactor. This file, located at the root of your project, should specify the rule sets Rector should adhere to. For instance, the following configuration upgrades PHP code to PHP 8.1: <?php declare(strict_types=1); use Rector\CodeQuality\Rector\Class_\InlineConstructorDefaultToPropertyRector; use Rector\Config\RectorConfig; use Rector\Set\ValueObject\LevelSetList; return static function (RectorConfig $rectorConfig): void { $rectorConfig->paths([ __DIR__ . '/src' ]); // register a single rule $rectorConfig->rule(InlineConstructorDefaultToPropertyRector::class); // define sets of rules $rectorConfig->sets([ LevelSetList::UP_TO_PHP_80 ]); }; Refactoring With Rector installed and configured, it's time to initiate the refactoring process. Execute vendor/bin/rector process in your terminal, and Rector will begin refactoring your code, illustrating the changes as it progresses. Review and Test While Rector often delivers flawless results, it's still a good practice to examine the modifications it makes. Ensuring that the changes conform to your project's requirements and haven't led to any unforeseen behaviors is a smart move. To further ascertain that your system's functionality remains unscathed, it's advisable to run your test suite. Remember, these steps aren't strictly necessary, but they add an extra layer of safety to your refactoring process. Rector also provides a "dry run" feature, where it displays the proposed changes without actually modifying the codebase. This feature is useful to preview what Rector will do before allowing it to alter your project. Conclusion RectorPHP is an essential tool for PHP developers looking to modernize their codebase efficiently. By simplifying the refactoring process and offering a seamless upgrade path for transitioning to more recent PHP versions, Rector empowers developers to focus on crafting high-quality software. Utilizing Rector means keeping your PHP code in sync with the rapidly evolving landscape of PHP development.

After watching this thread for a long time I finally tested ddev today and wow! I had never setup any environment so fast.

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

As a free solution for ProcessWire I would definitely recommend PrivacyWire. In my opinion it is the only viable solution at the moment. When that's not an option or more automation is needed, we tend to use Cookiebot. It's a paid service (they do have a free tier for small scale and limited requirements), but there are a few things that can make it worth the cost: It scans the site (as you mentioned) automatically and creates a list/table of used cookies, as well as identifies any cases where cookies are set without prior consent. At least here in Finland a list of cookies used on a site — including whether they are first or third party cookies, what they are used for, and for how long they are stored — is required. While one can of course keep such a table up manually, well... let's just say that especially for large and media-rich sites it's a whole lot of work. It has an automatic block mode that at least tries to automatically prevent the browser from loading anything that can set cookies. With PrivacyWire (for an example) you'll have to modify the markup of embedded script tags, iframe elements, etc. in order to load them only after consent has been given. It automatically generates and stores per-user consent history. At least here in Finland that is a necessary thing — site owners must be able to produce proof that the user has indeed given consent to storing data, and a separate registry is a must (said proof has to be available even if the user has cleared their cookies, localstorage, etc.) With paid plans it is very customizable. For an example we use a modified version of generaxion/cookiebot-accessible-template, since many of our sites need to be accessible. There are other services that do similar things, and I believe that some are cheaper than Cookiebot, but I have not had a chance or any need to properly dig into said other services. I'm only familiar with official guidelines and legislation as it has been implemented here in Finland, and also IANAL. Even with GDPR the actual implementation (and how that implementation is interpreted by officials) can vary from country to country ?

PrivacyWire is one option that works for PW and allows you to categorise and manage cookie choices. Also worth a look is cwsoft's new module (which I haven't tried) here: https://github.com/cwsoft/pwNoCookiesWithoutConsent

Hello everybody ? and thanks for your patience! Finally ended my sabbath and updated the module with pull requests and fix for the apostrophe thingy. Also added missing PW namespace + Composer support. There you go!

This is one of the rare things that are not instantly intuitive to I guess 99% of my clients! Have you considered adding a PR @Robin S ? Imho that's really an essential feature, thx for creating and sharing it! Just added it to RockMigrations default profile ?

@Jim Bailie In addition to the options you mentioned, if you put $myObject = new MyObject(); in your /site/templates/_init.php, then $myObject will also be available to all the page templates and the _main.php file, i.e. echo $myObject->value; As a benefit, it'll be automatically excluded from template files that don't use _init.php, such as the admin.php template file. If it's something that you might need on every page/template, but not necessarily, you may want to use it as a function in /site/ready.php that constructs it on first access, and then returns the same object on any later accesses to the function: function myObject() { static $myObject = null; if($myObject === null) $myObject = new MyObject(); return $myObject; } In this case, you'd use it like as a function with () appended rather than $ prepended, i.e. echo myObject()->value; This also has the benefit of using the same object (rather than creating another) if you happen to be calling $page->render(); on other pages in your template file(s). Another option: The way that ProcessWire does it is to use API variables, and you can add your own if you want. If you go that route, put in your /site/ready.php file: $wire->wire('myObject', new MyObject()); Then $myObject is available in any template files. The downside here is that it'll also be available to template files where you might not need it, such as the admin.php template file. So you may want to create it conditionally: if($page->template->name != 'admin') { $wire->wire('myObject', new MyObject()); }

Thanks, hope this module gets included in the PW-core.

I recommend using Rector for upgrading legacy code or modules. I have written a short introduction/tutorial how you can use it here: You can then select which files or paths should be updated and to which PHP version and it does automated safe refactoring on them. Most of the plugins should then work out of the box with PHP 8, I have converted several modules with it. New rulesets for rector are published whenever they are needed. It is a great tool.

Yes, it even works on PHP 8.3 and it's caching option is almost as fast as ProCache.

Thanks for your answer and explanation. I certainly will use PW and now I clearly know that your modules are also very usable in my project.

Hi. Thanks very much for your answer. Tools your writing are interesting, but application I want is not only for searching in database. I do not have vast experience with PW, but I have several sites built with it and I have to say it is wonderfull system. For me it is decided selection.

Hi @franciccio-ITALIANO What is the field type of texturl_background? What do you see when you view the page source? Gideon

Hello @PavelRadvan. I don't know how much experience with ProcessWire you have, and why you chose it. You can definetly develop an application to search through the database, but as much as I love ProcessWire, I think there are better tools for this task. First you have to export the data from Access to a MySQL or MariaDB. Then I would recommend using a tool like Directus (free, open source), with which you could Add Directus to an Existing Database (learndirectus.com) Or Filament (free, open source) which is a nice admin for databases and CRUD functionality. Or Laravel Nova.

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

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.

Hi, I think you can make it easier without dealing with 404 hook. You should give a read at this blog post about new URL hooks: https://processwire.com/blog/posts/pw-3.0.173/#new-type-of-hook-for-handling-request-urls

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.

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.

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.

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 ?

That's one of the things that "php rockshell pw-setup" does. DDEV is supposed to be used with docker, so you can use it on any OS. You'll get exactly the same environment no matter who is working on the project - that's especially great in teams. Laragon is not by far easier to use but a lot easier to setup. But you only need to setup DDEV once. Then it runs and runs and runs. And with ddev setting up a new project is by far easier then it was with Laragon for me. It's just "ddev config" and you are done. The biggest benefit for me is that you get a real unix dev environment. So if you have some special need for your server (eg creating thumbnails from PDF via poppler-utils you are out of luck with laragon). With DDEV you simply add poppler-utils to the config of the web container and you can develop everything locally and it will work the same on the live server. Also the config of the project can be added to the project's git repo. That means everybody can just do a git pull && ddev start and will have a working version of the project with all the settings and tools needed for it to run. You can't do that with laragon.