MarkE

My solution to this has been simply to add a warning in ready.php. The solution above looks neater though, and not dismissible (which may be a good or bad thing).

I quite agree. I think that, stylistically, the front-end editing approach is a good model to follow (assuming it works) and has the added benefit of already being familiar to many developers.

Interesting site. Slightly curious details regarding summer heat, where it seems there is no safe level, even in the coldest parts of the country.

I tend to have multiple items (pages) in my footers so there is more than one ‘footer’ page. The code is then included in _main.php. I guess they could be grouped into one page, but not sure of the merits of that.

I've put quite a lot of work into this now. There are lots of additional units added plus a greatly extended API. This enhances the formatting capability and introduces 'dimensional analysis'. So it is now possible to (say) multiply measurements and properly interpret the results. - e.g (as a simple example) speed x time = distance $speed = new Measurement('Speed', 'furlong per fortnight', 20); $time = new Measurement('Time', 'hour', 3); $length = $speed->multiplyBy($time, 'Length', 'yard'); d($length->render(['decimals' =>2])); Result is '39.29yd' Omitting the 'Length', 'yard' specification means that the result is returned in base units for the first compatible quantity for the computed dimension: $length = $speed->multiplyBy($time); d($length->render(['decimals' =>2])); Result is '35.92m' See https://github.com/MetaTunes/FieldtypeMeasurement for full details. The module is still alpha, so use in production systems is not advised. However, the functionality is now pretty complete but I have a bit of tidying up to do - and some more extensive testing in a new app. New units will probably also be added (but users can add their own anyway). Try it out and let me know of any issues or suggestions ?

Not sure if I'm being silly, but it seems to me that the core Field::exportData (3.0.184) has a bug in the following two lines $typeData = $this->type->exportConfigData($this, $data); $data = array_merge($data, $typeData); This code seems to cause the $typedata from the default fieldtype config settings to over-ride the actual field data. I have experienced a number of errors that appear to be caused by this. Shouldn't the 2nd line be this? $data = array_merge($typeData, $data); Per the PHP manual, the second array will overwrite the first if the keys match. I have written a hook (before Fieldtype::exportConfigData) to fix this by merging the data the 'correct' way before returning it to Field::exportData. Effectively it performs the merge the other way around and returns the already merged array (see code at end). However, I'm concerned that this may have side effects where child classes call parent::___exportConfigData($field, $data). Assuming it is a bug, would I be better just hacking the core until it is fixed. I haven't raised a core issue before, so am a bit nervous about doing so (and would need some time to build a simple case to demonstrate the issue). Code for hook is: public function afterExportConfigData(HookEvent $event) { $data = $event->arguments(0)->data; $value = $event->return; $event->return = array_merge($value, $data); }

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?