Leaderboard

You can mimic a basic authentication in the file "site/templates/admin.php" Therefor you have to handle a set of valid usernames and passwords in that file too, like in the following example: <?php namespace ProcessWire; $validUsers = [ 'user1' => 'pass1', 'user2' => 'pass2', 'user3' => 'pass3' ]; $validAdminUser = false; if(isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) { if(isset($validUsers[$_SERVER['PHP_AUTH_USER']])) { if($validUsers[$_SERVER['PHP_AUTH_USER']] == $_SERVER['PHP_AUTH_PW']) { $validAdminUser = true; } } } if(!$validAdminUser) { header('WWW-Authenticate: Basic realm="Adminsection"'); header('HTTP/1.0 401 Unauthorized'); echo '401 Unauthorized! Accessing this page needs a valid useraccount!'; exit(); } require($config->paths->adminTemplates . 'controller.php');

EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons. I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules: Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield. Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children. And there also is a helper module that takes care of cleanup tasks. This module evolved out of a discussion about my other Module FieldtypeImagePicker. It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield. When to use ? Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site. Suited for images that are used on multiple pages throughout the site (e.g. icons). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen: View of the field settings The module can be installed from this github repo. Some more info in the README there, too. In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory. My ideas for further improvement: - add ajax loading of thumbnails Happy to hear your feedback!

What @gebeer said. It could even be as simple as that in /site/ready.php if($page->template == "admin") { if(!$user->hasRole('your-role')) $session->redirect($pages->get(1)->url); }

@kongondo, have U any good news for us? Just say you're ok ;)

Works great - thank you! This is going to be such a useful module ?

Looks brilliant @gebeer A couple of minor things: 1) The "Include child pages of above page as source for images?" checkbox doesn't show as checked when it is actually checked. Typically the way to handle this is with a ternary conditional to set the checked attribute to "checked" if the value is "1", eg: $f->attr('checked', $data['enabled'] == '1' ? 'checked' : ''); 2) I didn't get an error message when deleting one of the source images. I actually wonder if you can hook into this and prevent deletion completely (unless the image is removed from being selected by this field.

You can use a hook to ProcessPageEdit::execute to redirect users with those roles to the frontend page. Make a new file /site/ready.php and put this code inside: wire()->addHookBefore('ProcessPageEdit::execute', function (Hookevent $event) { $restrictedRoles = array('admin', 'frontendeditor'); // list your roles here foreach ($this->user->roles as $role) { if ($role->name !== 'guest' && in_array($role->name, $restrictedRoles)) { $this->session->redirect($this->config->urls->root); } } }); This will redirect users with given roles to the homepage of your site. Note that this will restrict them only from accessing page edit screen in the admin panel. If you like to restrict access to the whole admin area for those roles, you would need to hook into Page::render or Page::viewable and than check if the Page has template admin.

Hi @benbyf Just ideas, I hope this helps: As far as I know, the closest module which at least partially could be used for such grid building is @Macrura's Inputfield Selectize: https://processwire.com/talk/topic/13549-selectizejs-modules-family/ Another idea – which also needs additional coding – but could be a working solution is to use @gebeer's new module FieldtypeImage Picker which is currently being polished: https://processwire.com/talk/topic/22665-module-fieldtypeimagepicker-pick-images-from-a-folder/ And for the grid part you could implement a grid builder with something like this: https://gridstackjs.com/ FieldtypeImage Picker could be used for setting the image, and the event of that selection could notify gridstack.js which could then set the content of corresponding the grid cell accordingly. As for uploading images on the fly, I have no idea about the possibilities, but if you can use ajax request in the correct order, then it might be possible to wire it all up. If a PW image inputfield is set to replace images with an already uploaded image having the same file name, then PW uploads and assigns the image to that page without the need to click the Save button, therefore images uploaded to the very same page could be made available right after being uploaded, provided FieldtypeImage Picker "be refreshed". You could consult Gebeer for such a possibility... Again, I am just brainstorming here.

And done ? 0.5.0 released

This week we’ve got version 3.0.147 out on the dev branch. Relative to version 3.0.146, most of the new commits (about 13 of them) are focused on resolving reports submitted at GitHub. I love refactoring existing code and adding optimizations and improvements to the core (and then writing about them in the blog). But right now I’m trying really hard not to! I’d like to have a new master version out before the new year, so the focus is on making sure the core is as absolutely stable as possible. Any time I refactor or add something new (or even sometimes when fixing something or another), there’s a chance of introducing new bugs, and it needs thorough testing on the dev branch, so right now the goal is that everything is thoroughly tested and stable before merging to the master branch. As a result, I’m trying to keep my hands off the core as much as possible, other than fixing obvious things that aren’t likely to introduce new code that needs testing. Please consider 3.0.147 release candidate 1 (RC1) for the next master. Thanks for all of your help and testing. Hopefully by (or before) 3.0.150, we’ll be ready for a merge to master. One way I try and take a break from modifying too much in the core before a master version release is to focus on other modules instead. That’s why last week I wrote about the new UserActivity module, and why next week I’ll be posting all the details for a new LoginRegisterPro module — one that I’ve been working on-and-off for more than a year, but have recently given it a lot of attention in getting it ready for release. I’ll save most of the details on LoginRegisterPro for next week, except to say that it provides an all-in-one solution for front-end login, account registration, profile editing and more. You might be wondering how that’s different from the LoginRegister module I built and released awhile back. That LoginRegister module was built for a very specific purpose and client, largely as a proof-of-concept. But there was a lot more interest in it than I ever expected, and several people suggested that there was a need that would be better served by the quality and support of a Pro module. The result is LoginRegisterPro, which is a full reimagining of that from the ground up. It does everything LoginRegister didn’t, in addition to everything it did. It goes much further in terms of security, reliability and customizability, and I look forward to telling you more about it. I may have it ready to release as soon as next week, but just wanted to make sure all the documentation was complete (and there is quite a lot of it so far). A couple other things I’m looking forward to working on here in the next month or so are the 2020 core roadmap and [finally] the new modules.processwire.com site. Thanks for reading and have a great weekend!

Attention: This is the thread for the archived open source version of RockPdf. This module is neither developed any further nor maintained nor will it get any fixes. Modules Directory: https://modules.processwire.com/modules/rock-pdf/ Download & Docs: https://github.com/BernhardBaumrock/RockPDF Please see the new version here:

I can't duplicate. I don't use _init.php, but I put this into home.php and basic-page.php: bd($user); bd($user->language); bd($user->language->title); And I get the same result, title is string.

Thanks! Hugely usefull! Think my main issue is the grid editing element so I might implement most of the site and leave the editable image/link section till last and maybe look at building something. I would like it to mirror the frontend as much as possible, so i could just use css grid and do some limited js stuff pushing the page id's, item number and span columns and rows into the database..... mmmmmmmmmmmmm

There is an old video around that shows how it could be done. It's the older version of ProcessWire in that video but it would work the same nowadays - just looks a bit different now. In terms of best workflow... it really depends on various factors as @bernhard already mentioned. I wrote about my personal workflow in or with ProcessWire here and here.

Hi shogun, welcome to ProcessWire ? imho that's totally up to you... It depend's solely on your preferences, other workflows, integrations, team members... I guess 1) would be easier in the beginning and 2) might make more sense after a while when you are more familiar with how pw works (and how you work with it). You can do a lot more than just inject some API magic into template files. For example you can do field rendering (https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/#field-rendering-with-template-files) or use Markup Regions (https://processwire.com/docs/front-end/output/markup-regions/) that open up a lot of possibilities but also make things more complicated in the beginning (if you are new to them).

Hi guys, thx alot for the discussion ? Good point. I think that should not be a problem. If there is an issue with the core, it should be easier to check a simple fix than to fix the issue yourself. If it was a complicated fix, this module might not be the right place for it. I've added @adrian as collaborator on the Repo - the goal is that this project is a "real" little community project ? --- Thx adrian, I've updated the description of the module: --- Actually I think it IS a module for the average user. See https://github.com/processwire/processwire-issues/issues/812 for example. This is a CSS issue that any webdeveloper can easily fix by some CSS rules. The only problem is: How to get the code properly into processwire. There are several possibilities: Overwrite the core css file (easy, but no option, of course) Create a PR (you don't know when it get's merged and you need a workaround until then) Use a module like Admin Custom Files (this works for CSS and JS, but this will not work if you need hooks for your fix) Add your fix via hooks in ready.php (you end up with a mess of hooks in ready.php and you need to copy over code snippets from project to project) Create a module for it (that might be too much effort for most users for simple fixes) The module makes it really easy to apply any kind of quickfix. And it makes it really easy to merge those fixes via PR's (for the ones maintaining this module). --- True! Nothing to add ? --- It's not intended for hacks, it's intended to fix issues that one would report in the PW issues repository until the issue get's fixed there properly. Hope that makes sense ? Thx, that's a good idea, thx ? --- Nice idea. I'm not sure how helpful automatic statistics would be though. I've got bad feedback on my modules implementing google analytics download tracking and numbers where small overall anyhow, so I'm really not sure how much help a "this fix was used 5 times since 08/2019" would be ? What do you think of a obligatory property for every fix that links to the related PW issue report. This would make sure that the issue is reported in the issues repo, seen by Ryan and users can vote for the issue there (give a thumbs up). That would also have the benefit that users can raise their voice there, comment things, add screenshots etc.; A lot better than some strange number where nobody knows what it shows exactly... --- Could you please try to do that on your own? I've added you as collaborator ? --- Thx again for all your contributions! Have a great week.

Hello, thanks a lot for your messages and applications. We are happy to have found someone who will support us. Regards Annemie

Here is my final init.php code for bilingual password forgot. if (wire('session')->language) { wire('languages')->setLanguage(wire('session')->language); } $wire->addHookBefore('ProcessLogin::execute', function($event) { if (wire('input')->lang == 'fr') { wire('languages')->setLanguage(7085); wire('session')->language = 7085 } });

Yeah, being out of context like this will be confusing I think. Could you try the getForPage() method to find the page that the repeater item is on and link to that instead?

New version v0.0.4 released https://github.com/gebeer/FieldtypeImageFromPage Is now fixed Implemented this. Also think it is better to prevent deletion of images as long as they still are referenced from other pages. In this case now a detailed error message is displayed which contains a list of pages that have references to the image, with edit links for those pages. Following the edit links (they open in new tab) shows only the relevant field to be edited on that page. Not sure this works in repeater contexts, though. Will have to test. Sorry for that, it was late last night. It is now fixed.

Also would be cool if it allowed you to choose multiple images from the page so you can create a gallery from the stored global images.

@szabesz ATM there is no option to choose whether child pages of the "image holder page" (home in your case) should be included or not. This would be a necessary option in your use case. Otherwise the inputfield would list all children of home as sources for images. Couldn't you just use another page as source for the images and than create the 2 fields "header image normal" and "header image tall" as fields with my fieldtype and assign them to all top level pages' templates? Anyways, sounds like an option to exclude child pages would be good. Think, I'm going to add this to the next release.

Hi @wbmnfktr It seem that your are using the wrong version - try the 1.3.12-ATO version on the dev branch please, it work as expected.

Nowhere. This is embarrassing. I forgot about language field when I rewrote the module for alternative graphql library. My bad, sorry. New Version 1.1.0 I updated the module to support languages now. Please upgrade and it should work fine. Sorry for inconvenience and thanks a lot for the feedback.

@adrian @szabesz I am already working on implementing with child pages.

@bernhard - just submitted a PR for the childTemplates and parentTemplates removal issue (https://github.com/processwire/processwire-issues/issues/802) https://github.com/BernhardBaumrock/PwCoreFixes/pull/1 One thing to note - I think you should perhaps set the autoload value of this module to 99999 - the reason being that Tracy's Admin Tools panel has a "Template delete" tool that allows you to delete templates that have associated pages in one step - it deletes the pages for you first and then the template. The problem is that because Tracy is set to autoload at 9999 it deletes the template before this fix is applied. The catch with loading this before Tracy is that then you can't use bd() calls to debug this module or the fixes you are writing for it, so not sure what is actually best ?

Please read this: https://processwire.com/blog/posts/pw-3.0.80/#pro-module-faqs then contact Ryan directly.

Thanks @gebeer - this looks really useful! I wonder whether it would be useful to have an "Upload Image" option so that site editors can easily add images to this global directory so they don't need to resort to FTP or engaging their developer to add new images. I suppose the alternative would be to create a "Global Images" page in the page tree and point this module to the /assets/files/xxxx/ directory for this page - maybe that's actually the better approach? Anyway, I can definitely see using this quite often!

The database will be the bottleneck. Use InnoDB and transactions. Find all items with the text "transaction" on this page: https://processwire.com/api/ref/wire-database-p-d-o/ https://processwire.com/blog/posts/using-innodb-with-processwire/ For an example of how they are used, find "transaction" in this: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module.php (BCE includes the copied supportsTransaction function, so it will work with older PW versions as well)

I fork long running processes to the background. You don't need PCNTL functions for this. In an import module which takes some minutes to run, I have a file "importworker.php" <?php namespace ProcessWire; include(__DIR__ . "/../../../index.php"); // bootstrapping PW error_reporting(2); // setting error reporting // ini_set('max_execution_time', 300); // 300 seconds = 5 minutes wire('log')->save('productimport', "starting import: " . date('Y-m-d H:i:s')); $importModule = wire('modules')->get("ProcessImportProducts"); $importModule->importController('start'); wire('log')->save('productimport', "Import finished: " . date('Y-m-d H:i:s')); Then there is a method for forking the heavy work into the background public function startImportWorker() { $path = $this->config->paths->siteModules . "{$this->className}/"; $command = "php {$path}importworker.php"; $outputFile = "{$path}output.txt"; $pid = shell_exec(sprintf("%s > $outputFile 2>&1 & echo $!", $command)); return; } All output of the importworker script is piped to output.txt. So I can see what happens when the process is running in the background. Some methods in my module echo stuff so I can see it in output.txt. Also for longer running loops in my module, I use the ini_set('max_execution_time', 300) method to prolong execution time. And I unset variables along the way to take care of memory issues. With some ajaxy JS, I get the contents of output.txt and show them inside a div#status in my module, so the user knows that there is sth going on. var ProcessImportProducts = { init: function() { $('#startimport').on('click', function(e){ e.preventDefault(); $.get($(this).data('href'), function( data ) { // console.log(data); ProcessImportProducts.pollResults(0); }); }); }, pollResults: function(timestamp) { var statusUrl = '?getstatus=1'; var statusText = $('#status'); // var loader = $('.loader').clone(); if(!timestamp) statusText.html(''); $.ajax( { type: 'GET', dataType: 'json', url: statusUrl, success: function(data){ // console.log(data); // if file has changed append data to statusText if(timestamp != data.timestamp ) statusText.html(data.message).append('<div class="loader"></div>'); // call the function again, this time with the timestamp we just got from server var timeout = setTimeout(function() { ProcessImportProducts.pollResults(data.timestamp); }, 1000); if(data.timestamp == 0) { clearTimeout(timeout); $('.loader').addClass('hide'); } // scroll to bottom of status div statusText.scrollTop(statusText.prop("scrollHeight")); } } ); } }; $(document).ready(function() { ProcessImportProducts.init(); }); EDIT: heres the part of my ___execute() function, that returns the status stuff for the JS if($this->config->ajax) { if($this->input->start == 1){ $this->startImportWorker(); echo 1; return; } if($this->input->getstatus == 1) $this->returnStatus(); } else { // module output to screen } Here's a good read about running processes in the background: https://medium.com/async-php/multi-process-php-94a4e5a4be05 Hope that helps.

That would be a masterpiece of course! As @szabesz already wrote... sometimes you want to take care of some fixes you need and aren't available at time. Therefore the idea of naming this module PWQuickFixes seems to be pretty accurate.

It would be, but as we all know, life is not as straightforward like that ? There are issues Ryan solves pretty fast after being reported, there are others that take more time and there are some which seem to take forever... and the worst category is in which he is only marginally interested. Also, what we might provide as a "fix" via a PR can easily turn out to be just a workaround and there is no point in submitting such a PR. For example, in all of my use-cases PageTable without an "add new" bottom at the TOP of the table is a UX nightmare, so I have a JS hack to clone the button from the bottom to the top. In my point of view I "fixed" this is issue, but in reality it is just a hack which would be a good fit for this module, I think. Maybe we should call this module PwQuickFixes which might better reflect its intended purpose: temporary workarounds until they get properly fixed. We just need stats to see how many of us is using a particular quick fix, and another way to make our voice heard is to add a kind nudge by asking the user to go to the related Github issue in order to make her/his voice heard too.

Maybe it is art, but you know what would be logical and efficient ? ..... fixing issues via PRs ?

Hey @bernhard - you've probably already seen this comment via Github, but I'll repost here for others. I like your proactive approach with module, but I fear that it might actually slow down fixing these things in the core because if users start adopting it, they'll be less likely to add their voice to the actual issue reports and so Ryan won't see that the issue affects other users as well. I hope I am wrong though and I really do appreciate your effort!

Similar background... totally different solution: 2,000 recipients 1 older lady weekly newsletter Nothing worked out good enough. No software, no CMS plugin, no nothing. For a small fee each newsletter she now gets kind of proofreading, formatting and everything her newsletter needs. She writes and sends the newsletter in her mail client (Thunderbird) to me, I copy/paste everything into a plaintext file, format everything, read everything, put it together in Mailchimp and send it out to her recipients. It takes about 20 minutes. Everyone is happy. As it works so well for her, she wants to send more newsletters with more content, more links in the future. Lucky me.

Hi Bernhard, I like the idea A LOT ? However, since it is your module, you should be the one to audit – at least from the security point of view – any PRs before accepting. Will you have time for that?

Tis the season to clean out the mechanical keyboard (first time in 7 years)...

ProcessWire is mature enough. But is not a ready-made solution for this niche, like the names you mentioned. I have made a system quite similar to what you've described here. But it was a lot of work. And it was made with PW to support dealing with objects already in PW. So I would support @wbmnfktr here. If you got time budget and the skills (or want to aquire them), and you know you will use ProcessWire for some things not available out of the box in the ready-made solutions, than go for it using PW. If not and you just need a quick turnover, use one of a plethora of ready made stuff. Just test it out out before making a final decision.

I have to admit that it doesn't look that bad for 7 years without a proper cleaning. I'm quite impressed actually. There is only dust and one bit of whatever... maybe paper. That's not a coder keyboard. Never! Where are all the chips bits, spilled soda and coffee stains and whatsoever? ?

You have 99029007164861804075467152545817733490901658221144924830052805546998766658416222832141441073883538492653516385977292093222882134415149891584000000000000000000000000 possibilities to put the keys back... ?

If you do not assign a title the autogenerated ID (Inputfield) will be taken. $inputfields->attr('title', 'Weird name'); To put the Inputfields (Tabs) in the right order you could use InputfieldWrapper::insertBefore() or InputfieldWrapper::insertAfter() instead of InputfieldWrapper::add(). Unfortunately this doesn't work in case of ProcessPageEdit. To get it working you need to add another hook to ProcessPageEdit::getTabs() The following code snippet should work. Place it in your /site/ready.php wire()->addHookAfter('ProcessPageEdit::buildForm', function ($event) { $page = $event->object->getPage(); if ($page->template == "bewerbung") { $form = $event->return; $inputfields = new InputfieldWrapper(); $inputfields->attr('title', 'Weird Name'); $inputfields->attr('name+id', 'WeirdTabNameAndId'); // we need both unique ID and Name $markup = wire()->modules->get('InputfieldMarkup'); $markup->label = 'Custom Lable'; $markup->value = '<p>Just a placeholder for any custom markup</p>'; $inputfields->add($markup); $pageEditTab = $form->find('id=ProcessPageEditContent')->first(); $form->insertAfter($inputfields, $pageEditTab); // inserting in the right place is not enough to set the tab order // we need the following hook wire()->addHookAfter('ProcessPageEdit::getTabs', function ($event) { $event->return = array_merge( array_slice($event->return, 0, 1, true), array('WeirdTabNameAndId' => __('Weird Name')), // should be identical to the weird name/title above array_slice($event->return, 1, null, true) ); }); $event->return = $form; } });