Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by MarkE

  1. 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.
  2. 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?
  3. 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()
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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 🤔
  13. 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?
  14. 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?
  15. 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.
  16. 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....
  17. 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?
  18. 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?
  19. 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 %=
  20. 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.
  21. MarkE

    Hanna Code

    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
  22. MarkE

    Hanna Code

    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?
  23. I used setting() because I needed to access the object in site-admin* as well as site-web. So I used your code and added: if (!setting('admin_site')) setting('admin_site', adminSite()); Both sites are in the same installation so use the exact same version Done that. Everything works except for the cross-site referencing as reported - I'm still getting a null page returned. (The code reversion problem seems to have been temporary). *Note: I need to access the object in site-admin because the availability page is running in site-web - called by $availabilityTable = $adminPage->runtime_markup_availability; (where $adminPage is the one that is currently being returned as null) but the runtime_markup code is in site-admin and needs to use the site-admin instance of wire(), not the site-web one. (Why is the runtime_markup code in site-admin? Because there can be multiple public websites which may or may not be PW sites and I want them all to use the same code to render the availability table which is defined in the admin site). Sorry if it's a bit complicated, but it was all working so well in 3.0.165! EDIT: The above is probably all irrelevant! The problem seems to be to do with the selector bodyFoot*=$host which is finding the correct page in 3.0.165 but not in 3.0.184. Using just "template=Availability" works fine and the found pages have field bodyFoot with the text $host. So I changed *= to %= and now it works! I guess at sometime the selector method got changed very slightly, so I will check for other instances of that. Anyway I'll keep the changes you suggested @ryan as they are an improvement anyway 🙂
  24. Just trying to update a multi-instance site to 3.0.184 from 3.0.165 but the cross-linking between the two sites no longer works. The two sites are /site/ - essentially the admin site for property bookings - and /site-web/ for the public website and which publishes availability from /site/. In /site-web/templates/_init.php I have: setting('admin_site', new ProcessWire($config->paths->root . 'site/')); and in /site-web/templates/prices.php I have: $adminPage = setting('admin_site')->pages->get("template=Availability, bodyFoot*=$host"); // bodyFoot holds permitted hosts list for PW sites bd($adminPage, 'admin page in Prices'); In 3.0.165 $adminPage is the correct Availability page. In 3.0.184 it is a null page. I have tried clearing FileCompiler from cache in both sites, but still get the same result. I also did a dump of setting('admin_site') in both versions and it looks identical. Is there anything in 3.0.184 that might have changed to cause this? Any other ideas? Thanks. EDIT: Another really weird thing. If I try and edit site-web/templates/_init.php to add debugging then it keeps reverting when reloading - like PW is editing my php file! This only happens with 3.0.184, not 3.0.165. Think I'm losing my mind!
  • Create New...