cwsoft

@BrendonKozYes that is exactly the issue. The method processInputFile executes on both upload and deletion using the file input field. The processInputAddFile does not allow easy access to the pagefile and the other infos like page object etc. needed to unzip the files to the designated spots. Thought there might be a PW way of preventing trigger to kick in (e.g. by adding data to return value object) or to detect inside processInputFile if this was triggered from processInputDeleteFile etc. The easiest method I came up with is to set a PW session variable inside the delete hook and check for it in processInputFile to skip the extraction of the ZIP file. This works fine, but I doubt that this is the ideal way of doing it.

@BrendonKozThanks for your suggestion. Basically an editor can upload a zip file with PDF participation certificates for courses from a page file field in the backend. Once the ZIP file was uploaded, the PDF files should be extracted to a folder inside site/assets/files/upload, which is protected via .htaccess from direct access. At the end of the year the extracted PDF files will be deleted by the course editor, by deleting the corresponding ZIP archive via pressing the trashcan icon of the page file field. The course attendees can download their PDF certificate after the course is finished from their course page available after frontend login. This is done by clicking a download button, which reads the binary contents of the corresponding PDF file and sends it as PDF file to the browser for download using PHP header functions. So the PDF files are not touched after upload until they get deleted at the end of the year. The PDF files should stay around until the end of the year or a predefined time period before getting deleted. So I do need two hooks. Upload of the ZIP file triggers the unzip task and the deletion of the ZIP archive should trigger the delete extracted PDF files task. Timing won‘t help, as the delete action should not trigger the unzip process again.

Hi. Added a "workaround" to solve my issue by setting a session variable at the end of the processInputDelete Hook to indicate, that the ZIP file was deleted. Then I check in the processInputHook if this session variable exists and is true to skip the part to extract the content of the ZIP file again. That seems to work. However I doubt this is the best solution to deal with this issue. Is there a more PW like way achieving the same without the ugly session variable hack? Any hints or tips on this topic are welcome.

Hi, I added the following hook into site/ready.php to extract the contents of an uploaded ZIP archive to a specific folder (site/assets/files/uploads). The first steps works just fine. // Hook into input file field to extract zip files into specific target folder. $wire->addHookAfter('InputfieldFile::processInputFile', function (HookEvent $event) { // Limit unzip handler to specific file fields on specific template pages. $pageFile = $event->arguments('pagefile'); $page = $pageFile?->page; if (!$page || $page->template->name !== 'XX' || $pageFile->field->name !== 'XX_zip') return $event->return; // Build path to specific target folder, where ZIP files gets extracted to. $files = $this->wire('files'); $extractPath = $this->wire('config')->paths->assets . "files/uploads"; // Ensure destination folder for files to extract exists. if (!$files->exists($extractPath, 'dir')) { $files->mkdir($extractPath, $recursive = true); } // Extract ZIP file into specific folder. if ($files->exists($extractPath, 'writeable dir')) { $items = $files->unzip($pageFile->filename, $extractPath); } return $event->return; }); Then I tried to remove the automatically extracted files from the specific folder, once the uploaded ZIP files gets deleted via the backend via the hook below (again in site/ready.php). The code below works standalone, but not in combination with the other hook above. Issue: Once the code in the delete hook (below) was executed, the code in the processInputFile hook (above) kicks in again, causing the unpacking of the files from the uploaded ZIP archive again. The ZIP file gets deleted during the process, but the unpacked files remain inside /site/assets/files/uploads. // Hook into file field to remove extracted files from specific folder once ZIP file gets deleted. $wire->addHookAfter('InputfieldFile::processInputDeleteFile', function (HookEvent $event) { // Limit unzip handler to specific file fields on specific template pages. $pageFile = $event->arguments('pagefile'); $page = $pageFile?->page; if (!$page || $page->template->name !== 'XX' || $pageFile->field->name !== 'XX_zip') return $event->return; // Build path to target folder. $files = $this->wire('files'); $extractPath = $this->wire('config')->paths->assets . "files/uploads"; // Delete zip folder when ZIP file gets deleted. $files->rmdir($extractPath, $recursive = true); return $event->return; }); Also tried to hook to processInputAddFile without success. Is there any way I can check inside processInputFile, if the hook was triggered by the delete or upload/add action? Thanks in advance for any hints or comments on this issue.

Had a similar issue with a local/live site where changing the session name to different names fixed the issues I had. However don‘t use special chars in the session name. Had issues with a - or . inside my session name, which caused weired issues, not easy to spot. Removing those chars and clearing session cache resolved the issues I had. Issue occured on last stable master and using PW $session API to check for logged in frontend users.

@ryanThank you very much for the code examples you provided for possible hook options related to PageClasses. Personally like the idea of including a page related hook file following the naming convention concept of PageClasses like PageNameHook.php. Will try some of those concepts soon in a real world project I am working on right now.

@ryanCould you comment on this quote from @bernhard in this thread. Hope I haven‘t missed it in this long thread. Having init and ready methods for page classes is something which was asked or proposed quite often in this forum or discussed at PWs Github repo in the past. Would be great to hear your thoughts on that and if this is something you may consider for future PW versions. Thanks in advance.

The PW forum is a place of the most friendly and helpful people I ever interacted with in web based CMS/CMF forums so far. What I learned from other forums is, that showing as much code you already tried (e.g. I put this code xxx into /site/templates/myfile.php) and asking a single question closely related to your code example (e.g. I expected to get x, but instead I see y) would help all involved people to better grasp each others standpoint and to provide better replies to specific questions. Cheers cwsoft

Nice and clean writeup on your local development setup. Thanks for sharing.

You need at least basic PHP skills and read through some ProcessWire tutorials before you could answer the question yourself. PW has a great community answering questions fast and trying to help and some great tutorials but less good out of the box frontend templates with a big wow effect for free. I would recommend to set up a local PW installation with a basic template first, read through the template, page, fields tutorials available and try to add some own templates e.g. showing some news extracted from child pages etc. PW has an easy API allowing to do amazing things, but you need some basic knowledge of PHP at least to have fun. Finally, you will never know if PW fits your needs unless you try to setup a small project with it and make your own mind out of it. No easy answer, sorry, but I would just try out myself and see what happens. Cheers cwsoft

Nice write up. Thanks for sharing.

As usual when I have a new idea and wonder how to implement it with PW core only, Bernhard has left a forum post pointing into the direction how to accomplish what I am looking for, even before I posted the question in the forum. I guess I own you a beer or two at least now.

Hi. I am using two site config files. The site/config-dev.php holds the DB settings and debug settings for my local site, the site/config.php holds all the settings for the live site. PW checks for presence of a config-dev.php and uses this file instead of default site/config.php if it exists. On my local dev setup, I do have a config-dev.php file next to my site/config.php file. On the live server I just upload the site/config.php or delete/rename the site/config-dev.php via FTP. Then I just ZIP my entire local setup once I am finished, upload the ZIP via FTP into the root of my live server together with an PHP unzip file and then visit the URL of the unzip script on my live server in the browser. The unzip scripts extracts all the files, sets right permissions if needed and deletes the ZIP folder and the unzip script itself once done. The local DB dump is done via DDEV DB export feature and then just loaded to the live server via phpMyAdmin or whatever DB tools the hosting company offers. This is done before I upload the ZIP file to my live server. For some extra safety, I create a dump of the live DB and rename the live site/ and wire/ folders to site.bak/ and wire.bak/ via Ftp before doing the update. This way I can easily revert back to the last working live state if needed - never needed for my PW sites so far, but happened in the past with some WP sites I tried to update.

@dan222You can get working a project in mind with PW quite easily by just using some basic features. I learn and discover new things every time I am using PW or read forum threads even after one year of using PW. Pretty sure I discovered only 30-50% of PWs goodies yet.

I created regular user accounts via the PW API with a specific role. Then I build a frontend login form using the PW API with the build in login throttle module and added a hidden honey pot field and a simple number captcha. Doing so allows to not expose the true admin login URL, which I keep for the side admin and two maintenance accounts. The admin template checks for the roles and throws a 404 PW error if a user with the role of the frontend-user would try to enter any backend page. So for those frontend users it seems the PW admin backend does not exist at all, while the site admin or the two other accounts can enter the PW backend parts which are accessible based on their roles and permissions granted.