MarkE

Yes. I’ll put the separately collapsible one on it’s own row then. Thanks a lot.

This is a simple question (I think) so I'm hoping there is a simple answer... My new Fieldtype module has an inputfield which is a fieldset comprising (up to) 4 inputfields. In the admin UI, each field has a caret to expand/collapse. However, clicking any one of them causes the same behaviour in all of them. I am enhancing this to add extra notes to one of the fields (quantity) that the user may wish to collapse, but collapsing that collapses all the input fields. I can set the initial collapse states differently, but after the first click, they all sync. Any ideas how to avoid this?

Found it! $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); $lengths = $pageArray->each(function($p) {$p->of(false);})->each('length'); I hadn't originally thought about chaining eaches, but of course that is possible if the result is a wire array.

I have a selector: $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); I would like an array of each of the 'length' fields. However, the field is an object and $pageArray->each('length') returns the formatted values; I want the unformatted objects. I thought perhaps I could use a callable like: $pageArray = $pages->find("template=basic-page, length.magnitude>0, include=all"); $lengths = $pageArray->each(function($p) { $length = $p->getUnformatted('length'); return $length; }); but it seems that only strings can be returned and those are concatenated. So it looks like I have to use a foreach() loop - which works, but I was expecting some neater shorthand. Any thoughts?

Apologies for some bugs introduced in 0.0.3. (Note to self: don't release code late at night). Hopefully all fixed in 0.0.4 which also adds a new static function FieldtypeMeasurement::addMeasurements()

v0.0.3 saves database value in terms of base units. Selector fieldname.magnitude then operates consistently regardless of what units are chosen - selecting values in terms of base units. Thanks for the tip @kongondo

This was my original approach, which I changed for a reason I can’t recall ?. I’ll reconsider. Edit: I think the reason was that the base unit definition might change. However, now I’ve got more mileage under my belt with this, I might be able to solve that problem.

Clarification: The above is a slight red herring regarding the isue raised as the multi-values are actually stored in the object as an array. The pipe format is just for the UI and the SQL DB.

Thanks for the comments @kongondo. As stated, it is POC at the moment so I am very open to suggestions for improvements ? . I have built it with an app in mind, but I wanted to do the fieldtype before proceeding with the app. No doubt using it in anger will result in some changes. I combined the magnitudes as pipe-separated in order to store them as a string in the DB. I am having second thoughts about this. In fact I am wondering about using arrays and then storing a json in the DB. At the moment, the queries don't work with combi fields, but there is a wider issue: if there are a mix of units in the field instances then numerical comparisons are meaningless. Therefore it is necessary to loop through the pages with measurements and convertTo() a common unit, then compare - this deals with combi units at the same time (assuming the common unit is single-valued!). I'm therefore thinking how could I solve that wider problem at the same time as the one you mention? Fair point. There is some error checking at the moment, but I still need to catch the exceptions which are generated and provide helpful messages. Hopefully the dropdown indicates the format and editors will soon get the hang of this. Again, I am open to better suggestions - it needs a balance between conciseness and idiocy-proof.

OK - I did this and it seems to work OK. @teppowas rather quick off the mark with the PW weekly report - I still have to add a lot of units and do some tidying (and remove debugging lines in case people don't have Tracy!). I will also add some notes about what I learnt doing this as the existing tutorials (such as @bernhard's) don't seem to cover fieldtypes which use the database. Support thread started at

EDIT: ************* Note that this OP relates to the original version of the module. Version 0.0.19 is now published to the modules library at https://processwire.com/modules/fieldtype-measurement/. As well as many bug fixes and small enhancements, it now also includes an 'in-field' interactive conversion feature and dependent-select in the config. See the readme on the module page for up-to-date details and see this post for a bit of a demo. ************* This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API. The API consists of a number of predefined functions, some of which include... render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m. A simple length field using Fieldtype Measurement and Inputfield Measurement. Combination units (e.g. feet and inches) are also supported. Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly. See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.

Not sure this is strictly a shared server issue. I find that I want to update data structures and settings pages, but don’t want to overwrite user-updated pages so database backup and restore (or phpmyadmin) doesn’t work. That’s why I wrote ProcessDbMigrate - still in alpha but usable provided everything is tested first. Or, if you prefer to do it all in code with the api, rather than in UI, there is RockMigrations.

I found a few more small bugs and have also greatly enhanced the help file, so that it is now available as a pop-out when working in the module. The new version (0.1.3) is at https://github.com/MetaTunes/ProcessDbMigrate. You should be able to replace the files in your ProcessDbMigrate directory with the new ones and 'refresh modules' to upgrade. @cjx2240, @antpreand @dotnetic (and anyone else): I'd appreciate your feedback as I am considering releasing this (as alpha) to the modules directory.

Thanks @bernhard. I’ve not really built a fieldtype module before. I’ve mod’d @Robin S’s RuntimeOnly and I’ve read your tutorial, but that still leaves quite a few knowledge gaps. I’ll give it a go, but may be back with more questions ?

I've been looking around for a fieldtype that can handle weights and measures but, rather surprisingly, can't seem to find anything. What I have in mind is a field that essentially comprises 2 elements - a (float) value and a (dropdown) measure (e.g. lbs, kg). It would also have an associated standard unit (usually an SI unit, I guess), which might or might not be in the dropdown, and each measure option would have a conversion factor to the standard unit. The value would be stored in the database as standard units. The measure options, standard unit and conversions would be specified in the input/details for the field, along with a default measurement option; these could also be set via API. If a user changes the measurement option in the dropdown, then the value would be amended accordingly (via AJAX). Is it possible to use the Combo ProField for this pupose (I don't have ProFields)? Would it be desirable to build a new Fieldtype module for this? Or is there a better way of achieving the same end?

Just a thought. Could you use $config->js() or $config->jsConfig() to set the field name having the focus and then have the js in admin.js defaulting to title if required?

Thanks for the comments @cjx2240. Sorry it has taken so long to reply. I have done quite a bit of work removing various bugs (there were quite a few!). I have also extended the functionality considerably to include a database comparison feature (allows draft migrations to be created based on database differences). There is also the capability to run custom code alongside the migration via hooks. The help file is now (roughly) indexed and available at https://metatunes.github.io/DbMigrate/help.html. The new version (0.1.0) is at https://github.com/MetaTunes/ProcessDbMigrate. You should be able to replace the files in your ProcessDbMigrate directory with the new ones and 'refresh modules' to upgrade. Please let me know if any of the snags you hit have persisted after the update (or any new ones encountered) and I will try and resolve them more quickly next time! I'm hoping that this version is a passable 'alpha' as opposed to the previous 'proof of concept' and will look to submit it to the modules directory if it seems sufficiently robust.

Needing to move on, I trashed and re-created the page. Weird dialog box when I trashed it: I clicked OK and it did go into trash though. So I think it's fixed, but I'm still pretty puzzled about what happened....

Or just a toggle field?

This is probably something really stupid, but I have one page that cannot be edited - instead it just downloads the index.php file when I click on 'edit' in the page tree. Any ideas?

Seems like the best fix for this is to add <IfModule mod_security.c> SecRuleEngine Off SecRequestBodyAccess Off </IfModule> to the .htaccess file. I wonder if this should be provided (commented out) in the default PW file?

bodyFoot is just a (CKE) textarea field in a page with template=Availability. It holds a comma-separated list of hosts which are permitted to access the Availability page in site-admin. $host is the name of the site-web host. So all the select is doing is checking that $host is in the list of hosts. I realise that it might have been better to explode the list and then check array membership but, ignoring that for now, I am puzzled by your example - I get "Yes" for both too. Examining the (real) situation a bit more, I added some Tracy debugging to the code as follows: $host = $config->httpHost; bd($host, 'host'); bd(adminSite()->pages->get("template=Availability")->bodyFoot, 'bodyFoot'); $adminPage = adminSite()->pages->get("template=Availability, bodyFoot%=$host"); // bodyFoot holds permitted hosts list for PW sites bd($adminPage, 'admin page in Prices'); $availabilityTable = $adminPage->runtime_markup_availability; This is the output with the real data (in 3.0.184): Replacing the %= by *= in the code results in the following: In version 3.0.165, the *= yielded the same result as %=

I did wonder if that might be the case. I need to use the setting in both sites, having just set it in site-web, and I thought setting() achieves that whereas adminSite() is not available to the other site. However, it seems I am wrong and that the adminSite() function is available in site-admin when that instance is called from site-web. So I removed the extra line and everything seems to work, thanks! bodyFoot was "<p>myText, some more text, ... </p>" and $host was "myText" so your explanantion is spot on and in line with the docs. However, *= worked in 3.0.165 with exactly the same values so it looks like something changed... No worries, it all works now, but I wonder if there might be a problem lurking for others if indeed there was a change.

The more I look at this, the more it seems to me to be a bug. The current method has the effect of not only removing the namespace, but also failing to add: if(!defined("PROCESSWIRE")) die("no direct access"); to the Hanna code. In my case, I have dozens of Hanna codes all just calling one hannaCode() function, so that I can maintain the codes in my IDE rather than the PW UI (much less time-consuming!). The upgrade seems to require me to edit every single Hanna code, which surely ought not to be the intention. I have therefore hacked my TextFormatterHannaCode.module to include the following in getPHP(): $php = '<' . '?php'; $openPHP = $php; $openPHPNS = "$php namespace ProcessWire;"; $firstLine = 'if(!defined("PROCESSWIRE")) die("no direct access");'; if(strpos($code, 'namespace') && preg_match('/(namespace\s+ProcessWire(?:;|\s*;))/', $code, $matches)) { $openPHP = $openPHPNS; $code = str_replace($matches[1], '', $code); } if(strpos($code, $openPHP) !== 0 && strpos($code, $php) !== 0) { // prepend open PHP tag to code if not already present $code = "$openPHPNS\n$firstLine\n$code"; } else { // otherwise insert our $firstLine security check $code = str_replace($php, "$openPHPNS\n$firstLine\n", $code); } This automatically adds the namespace and the 'die' to all Hanna codes and works (so far) for me. Perhaps others ( @adrian, @ryan?) might suggest a better fix or tell me that I've got it all wrong ? EDIT: I have raised an issue on GitHub for this

I am confused by this. Surely it should not be necessary to both add the namespace in the Hanna code AND call the function \ProcessWire\myFunction()? So I looked at the TextFormatterHannaCode.module - getPHP() method and found this: $php = '<' . '?php'; $openPHP = $php; $openPHPNS = "$php namespace ProcessWire;"; $firstLine = 'if(!defined("PROCESSWIRE")) die("no direct access");'; if(strpos($code, 'namespace') && preg_match('/(namespace\s+ProcessWire(?:;|\s*;))/', $code, $matches)) { $openPHP = $openPHPNS; $code = str_replace($matches[1], '', $code); } if(strpos($code, $openPHP) !== 0 && strpos($code, $php) !== 0) { // prepend open PHP tag to code if not already present $code = "$openPHP\n$firstLine\n$code"; } else { // otherwise insert our $firstLine security check $code = str_replace($openPHP, "$openPHP\n$firstLine\n", $code); } It seems that the method is removing "namespace ProcessWire;" from the Hanna code. Looking at the cached files shows this to be the case. In other words, adding "namespace ProcessWire;" to the Hanna code is pointless as \ProcessWire\myfunction() is still going to be needed. I really don't know why the above code has been added or what it is trying to achieve?