Search the Community

Hi, I'm facing a strange issue with priority values being output with colon (0,5) instead of period (0.5) which I guess is wrong. On some servers PW issues a warning to translate the locale setting: I have a site with a single language (German) and language support enabled to have the backend translated to German. So I translated the locale setting to de_DE.UTF-8 But now sitemap items that are generated through a hook will output 0,5 (which is correct for German locale). Other pages in the sitemap output correctly like 0.5. I have automatic sitemap generation disabled because I update it manually whenever some data changes that comes from an external XML and is converted to virtual pages on runtime that do not get saved to the DB. My code for adding those virtual page entries to the sitemap public function updateXmlSitemap() { $config = $this->wire('modules')->getConfig('SeoMaestro'); $items = $this->stellenangeboteXMLToPageArray(); // results in array of virtual pages $entries = array(); foreach ($items as $item) { $entry = (new SitemapItem()) ->set('loc', $config['baseUrl'] . $item->url) ->set('lastmod', date('c'), time()) ->set('priority', (float) 0.7) // casting explicitly to float doesn't help ->set('changefreq', 'daily'); $entries[] = $entry; } $this->addHookAfter('SeoMaestro::sitemapItems', function (HookEvent $event) use ($entries) { $event->return = array_merge($event->return, $entries); // add my entries to the sitemap }); $manager = new SitemapManager($config); try { $sitemap = $manager->generate($this->wire('config')->paths->root . $config['sitemapPath']); if (!$sitemap) { $this->wire('log')->save(strtolower($this->className), 'Could not generate sitemap'); } else { $this->wire('log')->save(strtolower($this->className), 'sitemap generated'); } } catch (\Throwable $th) { $this->wire('log')->save($this->className, 'Error generating sitemap' . $th->getMessage()); } } I don't know why the items added to the sitemap through my hook produce different output (0,5) from the items that are generated by the module (0.5). Could you make sure in the module code that the priority value is always being rendered as a float value, no matter what locale setting? That would be awesome.

Are you saying that there is something wrong with my proposed solution, or are you saying that there is something else wrong with the existing field type? I think either your post went over my head, or you may be misunderstanding my proposed solution. I think the solution is not actually that complicated. ProcessWire natively works with timestamps at runtime, which are always UTC-based. If I save something as a certain timestamp and then my PW/server/php time changes for any reason, I should be able to expect that the timestamp I get back from the field remains the same as the one I put into it. This is how it would work if the field stored a UTC string instead of a local string. Currently, what I get back is effectively a corrupted/meaningless value. I cannot change my $config->timezone once I've initially set it. What timezone the user sees or inputs a date in on the site's front end is a separate issue and is up to the programmer to determine and make clear to the user and convert to/from as necessary. But the programmer should be able to trust the timestamp they are working with when they save and retrieve it from the database. What does this mean?

Thanks a lot, dragan. You’re right, I should have specified the "where" a bit more – in this case I meant the page itself in edit mode as in your case 2. Anyway, I checked out the runtime markup field and it does exactly what I was looking for with very little effort. Perfect solution!

Where exactly? "on the admin page" is a bit vague... In the top menu? In a particular page when in page-edit mode? In the page-tree? elsewhere? For use-case 2, you could try https://modules.processwire.com/modules/fieldtype-runtime-markup/ Another very useful module is https://modules.processwire.com/modules/page-field-info/ - especially if you need to provide contextual information based on your selection (checkboxes, radio buttons, page fields, options...).

New showcase entry, for Aaron Copland, composer. https://www.aaroncopland.com/ Features Filterable/Searchable Works Listing with category, publisher, instrument, tag, keyword, or year range filtering Each work has a page showing meta data, as well as related media like audio, images, video, and related events & news. Works are cross related at various levels, as Copland would sometimes use sections of one work in other works Microdata (json-ld) for site, person, works, images, news and some events Ability to display embedded media like Spotify, Youtube/Vimeo, Getty Images, Archive.org etc. Fast autocomplete site & works search Modules used Admin Custom Files AOS Page Field Edit Links Auto Smush Batch Child Editor Custom Inputfield Dependencies Admin Comments* Secure Files Font Awesome Pro Import External Images Autocomplete for CK Editor Inputfield Selectize Simple MDE Visual Page Selector Font Icon Picker Page Field Info Page Table Extra Actions Pages 2 PDF Changelog Dashboards Process Documentation Settings Factory Restrict Tab View Selectize Template & Field Tags Prev/Next Tabs Text Input Awesomplete Get Video Thumbnails Ion Rangeslider Runtime Markup Config Form Inputfield Color Inputfield Field Descriptions Extended Cookie Management Banner ProCache Lister Pro Profields (Table mostly) FormBuilder Various custom modules *Admin Comments is a module in development that enables site admins/editors/managers to add comments to pages in the backend and to optionally notify other site admins/editors/managers. Possibly to be released in directory soon.

Hi, while working on 2 new configurable modules (with a lot of config settings) I encountered that the module config is not created/saved to db when the module is installed. You need to hit save to write the default config to database. This is a problem if I need some of these config values at modules runtime. Wouldn't it be better to save the default config values of the module on module install? Do I miss something here?

Since you have an array(ish) $clearPages, it looks like you want to recreate the cache for depending pages too (blog categories/tags pages etc.?) so I'd guess you'd have to make a request for each of those. It might become a runtime issue if you have multiple complex pages to render, but the worst that could happen is that rendering breaks at some point and the first request to an uncached page is slower.

When I installed Processwire for the first time, I noticed that Admin sessions were not lasting for a long time and it was very common to be logged out. Reading this forum I found useful information, but I could not solve this issue. I tried to modify site/config.php adding $config->sessionExpireSeconds with different values, but without success (for your awareness sessionExpireSeconds default value is 86400 seconds, ie 1 day .. so quite enough!). OK, I had no time to go deeper, so I kept doing what I had to do ... being happily logged out … time to time. Few weeks later while studying Session.php in wire/core/ I got the hint (please read the commented text) which helped me to understand how to solve it: if(ini_get('session.save_handler') == 'files') { if(ini_get('session.gc_probability') == 0) { // Some debian distros replace PHP's gc without fully implementing it, // which results in broken garbage collection if the save_path is set. // As a result, we avoid setting the save_path when this is detected. } else { ini_set("session.save_path", rtrim($this->config->paths->sessions, '/')); } } Uh! Yes, my VPS uses Debian 9 ! So I quickly did a test: echo ini_get('session.gc_probability'); echo ini_get('session.gc_divisor'); echo ini_get('session.gc_maxlifetime'); The session.gc_maxlifetime was rightly set to 86400, but session.gc_probability was 0 ! As you can easily get from Session.php routine, if probability is 0 bye bye PHP's session garbage collection and of course PW will not set the save_path. But why probability is set to 0 ?? This is due to the fact Debian/Ubuntu Linux overrides standard PHP’s session garbage collection by setting session.gc_probability to 0. As a consequence PHP’s standard session garbage collection will never run. Instead Debian/Ubuntu sets a specific Cron job for garbage collection with a duration of 1440 seconds, ie 24 minutes. This determines the max session duration. If you try to change session.gc_maxlifetime through $config->sessionExpireSeconds=86400 or ini_set('session.gc_maxlifetime', 86400) it will have no effect and sessions will be deleted at intervals of 24 minutes (or within 54 minutes). The Cron job garbage collection duration is defined at php.ini level, and runtime changes to session.gc_maxlifetime will not affect the Cron job timeout. Uh! Of course the simplest solution would be to change session.gc_maxlifetime in php.ini. However sometimes this is not possible (shared hosting). Another point to consider is that this change may affect multiple applications running on your server. Instead of modifying php.ini, personally I preferred to enable PHP's session garbage collection locally for Processwire only. Majority of the code is already written in PW Session.php, we have just to take benefit of it. Let's go step by step. Let's open site/config.php and do the following modifications (I choose to implement 14400 seconds session time, ie 4 hours): /** * Reduce inactivity timeout (original 86400 = 1 day) * How many seconds of inactivity before session expires */ $config->sessionExpireSeconds = 14400; /** * Enable Session Garbage Collection * Garbage Collection is disabled in Debian as default (probability set to zero) * Enable session garbage collection with a 1% chance of running on each session_start(); * Chance calculated as gc_probability/gc_divisor * Session path is defined inside wire/core/Session.php and points to site/assets/sessions * Thanks to this modification session now takes into account gc_maxlifetime set in config */ ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100); Do not forget to lock site/config.php after modifying it. Here it is! We are done! After we have set gc_maxlifetime (through sessionExpireSeconds), enabled the garbage collection (gc_probability=1), and set its intervention probability (gc_divisor=100 ie 1% chance), we can rely on Session.php where the a session path (session_save_path()) is defined, and session is started (session_start()). In the development session of our browser let's look for our session cookie: if you go to site/assets/sessions you will find your corresponding session: Please note that during development phase, likely having little traffic, the number of sessions may grow and they will not be deleted. This depends from the 1% chance of deletion. If you want to test garbage collection is properly working or just to make sure sessions files are regularly cleaned during development, you can decrease gc_divisor to a lower rate(10=>10% ... 2=>50%). Do not forget to reestablish gc_divisor = 100 when moving to production. I hope some can find that tutorial useful in the future ... and may save several log outs!

Thanks for the reply @horst! I was kind of hoping to get some feedback from you. I fully get the point about issue with uncontrolled auto mode but I don't quite understand what you mean by binding compression to defined suffix option. Currently auto mode is hooked after Pageimage::size and (if enabled) compression is done when given size is allowed, type matches (png/jpeg) and API is available (client connected and monthly compression limit no exceeded). By adding custom image sizer option we could disable auto compression on cases where further image manipulation is done and then handle it manually last in chain or do you have something more sophisticated in mind? $image->width(300, array('tinify'=>false))->pimLoad('prefix')->someManipulations()->pimSave()->tinify(); By the time it's also not prohibited to do re-compression to the images - maybe we should restrict such a use cases: // tinify already tinifyed image $page->image->tinify()->tinify(); // tinify resisized (and compressed) image when auto mode is enabled $page->image->size(100,100)->tinify(); I was thinking about forcing (jpeg) quality to 100% but then I thought we don't need that since if one want's to compress images sized at lower quality, why to restrain that. But when you say lower quality actually makes higher filesize we sure need forced 100%. Since compression is done to existing pageimages, we can only force 100% when image is resized by PW. Do you think something like this could work or again, do you have something else in mind? 1. Hook before Pageimage::size - Check for compression and if ok, save filename to runtime variable. 2. Hook before ImageSizer::resize - Set pageimage quality to 100% if jpeg and filename matches to the one in runtime var. 3. Hook after Pageimage::size - Do the compression and return tiny variation of a pageimage. Also I'd need your help (or maybe from @ryan) with resized images on rich text editors. First I thought hooking Pageimage::size would take care of this one also since it looks like that here in ProcessPageEditImageSelect::executeResize() but for some reason hook doesn't bite. Can you tell me why?

@dragan I want to detect whenever $user->language is changed during runtime, i.e. any changes after startup, including all related API calls like $languages->setLanguage(). I need to change the locale setting of the library I'm using for displaying dates in the frontend and would like to cover the scenario of dynamically setting the language for output purposes.

Now that the major update for my ImagePicker module is out, I wanted to share how I managed to make images from a folder in site/templates/ behave like a Pageimage with full resizing/cropping capabilities. This was probably the biggest challenge in developing the new features. I first thought to create a hidden page in the page tree that will hold all these images. But this would not have been a clean solution. So I took a closer look on how the Pageimage and Pageimages objects are constructed. Finally I decided to use a virtual (or fake) page to hold the images. It required some method overriding of the Page class and the PagefilesManager class to adjust the paths. Normally images for a page can only live in a folder in site/assets/files/pageid. By manipulating the path of Pagefilesmanager I was able to create a custom ImagePickerVirtualpage object and assign the images from the folder to that page. The virtual page is created at runtime and the DB never sees it. It took quite some trial and error to accomplish this. But finally, you can now manipulate these images just like any other Pageimage object (resizing/cropping). The resulting image variations will be stored in the same folder. There is one little stumbling block. I use an existing images field from the site my field is installed on and assign it to a virtual template of my virtual page. This field then holds all the folder images. I figured that every site that will use my module will already have an images field installed. Very rarely this will not be the case. So for the time being I am leaving the logic as it is. If I find people running into problems, I will adjust this. Code can be found here. One more thing that offered some challenge was storing the data as JSON in the DB and have it fully searchable through the API. Luckily I found an old (and abandoned?) module JsonNativeField from @BitPoet that does just that: store values as JSON and make them searchable. So I borrowed the DB schema and most of the getMatchQuery logic from that module. I still have 2 extra columns for pageid and filename in the DB table. These make sure that in the Pagefinder you can use subfields. Kind of redundant info in these columns but I couldn't figure out another way of making the subfield search work in Pagefinder. If you happen to know how to accomplish this, please enlighten me. Main advantage of JSON storage is that my image field can be used with the marcrura's SettingsFactory module. Also storing values of multiple images this way will be easy and will come in handy once I extend my module to support multiple images.

// site/ready.php $wire->addHookAfter("Inputfield::render", function($event) { $field = $event->object; if($field->name !== "yourfield") return; $event->return = "<a href='foo/bar'>Your link</a>"; }); You could use one of the Runtime Markup Inputfields or something like the hook above (untested - just an example to get you started).

Yeah. You can do a lot of fancy stuff in wakeupValue(). You can even create run time values and add them as properties in your $field object, or even fetch data elsewhere and add these as runtime properties, etc.

@adrian @eydun Made some progress and have a working version that is compatible with @Macrura's Settings Factory module. I switched to handling my field value as json. Haven't published the version yet as I'm planning on incorporating it into the yet to be developed new ImagePicker module. If you want to have a peek, I can publish it to a separate branch on github. Just let me know. First I was in doubt about using json for the field runtime value and for storage. But now I'm confident that this is the way I will go with the new ImagePicker module. So that one will be compatible with Settings Factory. The next days I will be working on combining this module and my ImagePicker (pick from folder) into one with the additional feature of letting the user choose an image from the page this field liveson. The resulting module will be released under the name ImagePicker. Hope I can get it out before Xmas.

Are there known limitations in the plugin? For example i cannot resize an image. Then I wanted to get the original image but I cannot get the url. $image->url gives me just the folder where the image is but not the file-name. $image->basename gives me nothing. Textfields are working as expected. "PHP Runtime Code Mode" is set to "Paste PHP code".

I am wondering what input field is the best to select the position of a text-layer on an image? #1 The easiest would be a select options field as dropdown with the options: north, north-east, east, south-east, south, south-west, west, north-west, center Or a less compass like version: top, top-right, right, bottom-right, bottom, bottom-left, left, top-left, center. #2 Use the focus point of the image, so you can position the layer anywhere, but you lose the ability to really focus on something if the uploaded image has a different ratio than the rendered image in the frontend. #3 Use RuntimeMarkup (https://modules.processwire.com/modules/fieldtype-runtime-markup/) to display (and eventually even manipulate) the select element from #1. (I did not try this one) #X Ist there a more elegant way that offers more visual feedback, like 9 squares (3 columns, 3 rows) with radio buttons or something like that?

To store data in a database table there's no need for any custom fieldtype. These are only needed if you want to create custom fields. If your module does just need a place to store e.g. configuration, you could also just use standard sql queries and if that's to bare bone there's always the option to let a orm library handle it or rather any library that abstracts the sql queries for you. There's also the option to use the module configuration automatisms to store information, which is stored json encoded, but might be enough for smaller configurations. It's true that fieldtype development is not very well documented officially, but it's actually not much different from what the teaser video in the starting post does show besides the UI factor. It needs a table column setup (getDatabaseSchema()) and some runtime to database conversion (sleepValue()) and db to runtime conversion (wakeupValue()). While the fieldtype events plugin is mentioned in the forum as kind of entry point to fieldtype development I found it a bit overwhelming at first, as it's starting out as multi-value field and is therefore more complex than it would need to be in the beginnings. With just extending the core fieldtype class and changing up those three methods you should be able to get a fieldtype working and then you can add functionality like sanitization or subfields and so on on top of it.

@verdeandrea Sounds like a cool project! If I had to do this, I guess I would go a similar route like @wbmnfktr suggests. However, gradient generators are a lot more work than just (single) color-pickers. I'm not sure it's worth re-creating all that stuff just so your authors can finally insert some CSS for a given section. I would perhaps rather use a markup inputfield*, and just open a gradient generator in a (pw-) modal, and instruct the editors to copy and paste the generated CSS into a regular textarea. Would certainly not look as polished and streamlined as a native PW inputfield, but it would get the job done way faster. * https://modules.processwire.com/modules/fieldtype-runtime-markup/ or https://processwire.com/talk/topic/21982-rockmarkup2-inputfield-to-easily-include-any-phphtmljscss-in-the-pw-admin/

When using PW's API, you should always consider your code to be operating as a kind of superuser, just like in PHP. In find() operations where you are retrieving multiple pages that you don't know exactly what they will all be, it's a sensible default to exclude "hidden", "unpublished" and no access pages, unless you request otherwise. This is there as a matter of convenience and pagination, not security. Of course you can override that (when you want to) with the "include=hidden" or "include=unpublished" or "include=all" options. Whereas with get() you are being very specific about what you want–a single specific page. Otherwise why would you get() it? Neither find() or get() are intended as a primary means of access control–we have other methods for that (see below). They are methods setup to operate in the most common use cases and keep your API calls as short and simple as possible. Just because find() filters out hidden, unpublished and no-access pages by default does not mean you should count on it for access control. That's because the pages excluded from a find() don't include runtime access control, just that which is stored in the DB. Further, the behavior of whether or not a no-access page shows up in a find() result (that isn't overridden with an include= directive) is configurable with template access settings. Granted, in most cases find()'s defaults are giving you exactly what you want in terms of excluding pages the user can't view (for your convenience), but that's not the entirely of PW's access control, which supports runtime hooks. PW's job is to provide access control for the request, but not for your own code, that's the developers job. PW intends to give you, the developer, access to everything (like you would with jQuery and the DOM), and you decide whether or not it should be available for output. PW provides you with some handy access control methods to help with this: $page->viewable(); // is the page viewable? true or false $page->viewable('field_name'); // is the field on page viewable? true or false $page->editable(); // is the page editable? true or false $page->editable('field_name'); // is the field on page editable? true or false If you want to have you own get() and find() that operate under different defaults, this is easy to do with hooks in your /site/ready.php file. For instance, this would add a $pages->one("selector"); method that automatically does a viewable() check for you and returns a NullPage() if the page is not viewable: $pages->addHook('one', function($event) { $page = $event->object->get($event->arguments(0)); if($page->id && !$page->viewable()) $page = new NullPage(); $event->return = $page; }); Would there be value in adding a method like the above to our $pages API by default? Maybe. It wouldn't benefit my own API use, because the only time I use $pages->get() is because I want to get something without conditions. But if it would be super handy for others I'm happy to add it. Here's another example, lets say you want a method in $pages, like $pages->all("selector"); that always returns all pages with "include=all" implied: $pages->addHook('all', function($event) { $event->return = $event->object->find($event->arguments[0], array('include' => 'all')); });

This sets the format for the input of dates/times (dateformat in the datepicker API), but it does not change the language of the datepicker UI, because this happens by including or not including those translation scripts you mentioned above. They basically set the datepicker to be in a certain language and don't just "make the translations available". Technically you can make jquery datepicker switch language at runtime, but I guess not including translations when not needed is the simpler solution. Edit: As to why the core itself doesn't handle including the correct files: ProcessWire doesn't have means of identifying languages. You can name your languages however you want. So it cannot map languages created by the user to something like the path for the datepicker translation, because it doesn't know a certain language is supposed to be e.g. german in the first place.

This week’s dev branch version brings you improvements to ProcessWire’s $input->cookie API variable, plus it adds the ability to modify system URLs and paths at runtime. This post also includes some examples to demonstrate just how useful this can be— https://processwire.com/blog/posts/pw-3.0.141/

You can just change $page->template->contentType and $page->template->altFilename at runtime… $html = $page->render(); $page->template->contentType = 'txt'; $page->template->altFilename = "Mail.txt.php"; $txt = $page->render(); $count = $this->mail->new() ->subject($subject) ->body($txt) ->bodyHTML($html) ->send(); For me, altFilename actually is enough…

That's not really true. Ryan's Dynamic Roles module does add additional sql clauses to ensure dynamic roles are fully resolved at the database level. Sadly is the module is not very well maintained and it could also be build a bit more flexible (e.g. matching on calculated values instead of just "membership"), but it is possible. This to me sounds like a very hacky workaround. You initially said you don't want to bloat the system with hooks. Blacklisting IDs and filtering them at runtime is very likely to be way worse for performance than a handful or two more hooks.

you could assign a runtime parameter to them, see this topic for an example: https://processwire.com/talk/topic/10920-remove-duplicates-in-a-foreach-loop-but-count-them/?p=102592 notice how this assigns a count as a runtime parameter: $i->useCount = count($pages->find("interests=$i"));

Hello @kongondo Any news on this issue? I also run into it when trying to export a textarea field via the standard field export feature of the admin. I don't really need Runtime Markup, maybe you can give me a quick guide on how to remove it manually (inluding how to clean up the db if needed?). Has this version been version published yet? Thanks in advance.