Search the Community

It looks like this module could allow for the introduction of field content prior to compiling - is that accurate? Is there anything special that needs to be done to prioritize it at runtime before ProCache? I'm looking to be able to push field values from SettingsFactory into the LESS file preproc.

I'm looking for an inputfield module that might allow the entry and evaluation of a conditional expression (following php syntax). My use case is an admin function for writing pro-forma emails/letters where some components of the pro-forma are dependent on conditions determined by an admin user. The pro-forma is then cloned for use and the relevant components are included depending on the runtime value of the conditions. The conditions usually include hanna codes as the items to be compared. This is implemented in a parent-child structure, where the main mail body is in the parent and each child then has a condition (textarea) field and a body textarea field for the optional text relating to that condition. As an interim solution on my dev machine, I am just using eval() to evaluate the conditions, but I really don't want to use this in the live environment. My idea is to use an approach similar to that for hanna codes to store the php and render it. This would be (somehow) wrapped in a new inputfield module (extending InputfieldTextarea?) with an evaluate() method that would return true or false as appropriate. It would be placed inside a try...except structure to catch syntax errors etc. It seemed to me that this might be quite a useful utility module and that someone might have developed something similar, but I can't find anything. Does anyone have any pointers, or will I need to start from scratch? If the latter, then I'd appreciate some help along the way as I am a bit of a novice in these matters.

Can you try a few different things for me: 1) Empty the PW trash 2) Do a field export (from the main fields list page) 3) Install the core ProcessPageClone module and click the new "COPY" page list action button If those all succeed without error, I'll revisit, but otherwise I'll need to update Tracy to be PW 3.x only so that it avoids the FileCompiler completely. That would solve the Console and APIExplorer panel error. The PW Info panel error is due to the Versions List feature trying to check if the system allows runtime modification of max_execution_time so I could conditionally remove or deal with that, but I'd like to make sure those other core PW things work on that host first. It's also weird how one.com seems to disable set_time_limit / max_execution_time some other way - ie not in disable_functions - make it much harder to detect.

@jonatan - looks like you used http://modules.processwire.com/modules/fieldtype-runtime-markup/ rather than https://github.com/Toutouwai/FieldtypeRuntimeOnly but they both do much the same thing. Anyway, glad you got it working and thanks for chiming on that Github request - that visibility stuff definitely needs an overall.

@adrian Thank you so much!!!!! ?☀️??? And thank you for such an amazing response time! - Done! - Worked like a charm!!!! Strongly back on the I-love-processwire-and-think-it-is-so-amazing-train! ??? ✅ Solution: Installed RuntimeMarkup Fieldtype module, made a new field with that type: DETAILS > : Edited runtime php file: site/templates/instagramaccountid.php: <?php namespace ProcessWire; $instagram = $modules->get("InstagramBasicDisplayApi"); $data = array('username'=>''); $account = $instagram->getUserAccount($data["username"]); $username = isset($account["username"]) ? $account["username"] : ""; $at_instausername = "@" . $username; echo$at_instausername; ?> Result: One piece of beautifully dynamically called data shown in as sweet plain text in the defined field in the template: Could be really cool though if this kind of custom field would maybe become integrated in the core? As well as an "locked / unlocked" option for all fields? Thanks again! All the best, Jonatan

Hi @jonatan and welcome to the forums. The "Open when populated + Closed when blank + Locked (not editable)" is the closest to what you are looking for. You might actually want to add your support to this request: https://github.com/processwire/processwire-requests/issues/346 Back to your original question, I haven't used Mystique, so not sure what its limitations might be on this front, but I wonder if you can make use of https://github.com/Toutouwai/FieldtypeRuntimeOnly to add the instagram data in a runtime field.

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!

Check out Runtime Markup: http://modules.processwire.com/modules/fieldtype-runtime-markup/

@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.

CKEditor is stripping out your code since <healcode...> is not a valid HTML tag. You can tell it, via its ACF and/or Extra allowed content settings, to allow that tag, though am not sure even that would work. Another possibility is to use Hanna Code to insert that code at runtime. Parameters would have to be passed to it (the values you want the client to be able to change) so as to render them at runtime. The Hanna Code would be could like so in your body field: [[widget a=value1 b=value2 c=value3]] where a, b and c are the parameters whose value the editor can change. You can rename them to something your client would understand, e.g. type,partner,id, etc...However, do you still want your client to be editing the Hanna Code like that? Alternatively, you can create a field(s) to store your editable values and via the Hanna Code, tell it to read from that field(s). Or, if the values will always be coming from a set pool, you can save them beforehand to a pagefield. The client would then have select the applicable values in that pagefield. Hanna Code would then grab the values from that pagefield. Note that the above is not the Hanna Code code itself; just how to call it on your page. Anyway, please describe your scenario with a bit more specifics so that we can tailor our responses to that.

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?

@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/

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.