netcarver

@OrganisedFellow $a = "Hello"; // Assigns the string "Hello" to variable $a. $a .= "Hello"; // Tacks "Hello" onto the string that is already in variable $a. Assignment vs String concatenation.

@valan Not sure if this is related but there's an open issue on github regarding https-only templates (they're meant to redirect from http to https but don't in 2.5) Posting an issue on github might be a faster way of getting a response from Ryan about your problem.

@Philipp Welcome to the UK. Are you going to be in London for the whole time you are over here?

Hi Sven, An idea off the top of my head (and totally untested): could you make your module a configurable module with a hidden field set to the current module's version. During your init routine you'll get given that value so you just compare it with your module's current version and if your current version is greater then call your update routine to alter the table as needed. Knowing Ryan, there's probably a way to do this built-in but I'm currently unaware of it.

After a nights sleep I've figured it out. It was indeed the rendering of the options in the underlying select that was the issue. Commenting out lines 57-64 of InputfieldAsmSelect ___render() fixes it for me. I'll now hook that method to provide my own implementation that doesn't put all the selected options at the end. Hope that helps and thanks for looking

Hey everyone, I'd like to be able to mod InputfieldAsmSelect a little with what seems like a simple mod but I've been hitting a wall with it. What I want to do is simply stop the pre-selected options from appearing at the bottom of the Asm select dropdown and instead have them appear in their natural place in the list. So, instead of this (with selected moved out-of-order to the end)... ... I want this (with selected items in their original position)... I know that when I select or deselect an option - without saving the form - the item stays in its initial, correct, position. But once I save the form, all the selected items seem to be sorted to the foot of the select dropdown - so I assume that this is something to do either with the initialisation of the field in its js file or perhaps with the code thats generating the initial data to fill the list... but I can't seem to work out where this happens. Can anyone provide me with a clue?

@suntrop Sorry to hear about the slow-down. What version of PW did you upgrade from?

Ah, yeah, that would do it, thanks Joss. I had a single template selected for children of the parent node so that'd be why I was seeing the re-labelled title straight away.

Hmmm, no idea why that might be, it's working fine here on 2.5.4dev for both new... and existing pages... My "Full Name" field is the re-titled "Title" field in the above shots. I also tried renaming it to "Full Name (ex Title)" - just in case the brackets were messing with things - but that works fine as well.

@Peter This might not be exactly what you want but I think you can get a long way towards making things easy using PWs existing per-template label feature for fields. Just edit your Staff Directory template and locate the "title" field in the list of fields and click on the word "title" to bring up the per-template field config sttings editor. You can now change the label for the title field from "Title" to "Full Name" and save that and the template you should now be able to use the title field and it will be displayed as "Full Name" on every page you edit or add. In effect you can re-purpose the title field and remove the need for a separate full_name field. I know that might not be 100% of what you are after but it goes a long way toward it.

I've just posted a Fieldtype and Inputfield module combination that support the use of MySQL time fields in ProcessWire. Ryan's Datetime module is great but I needed something that dealt specifically with times for a scheduling system and this is one of the results. For 24 hour clock format ('HH24MM') you now get a clock-picker pop-up by default... ...but you can inhibit it if you don't want it... Although the input time format is selectable, as this is stored as a MySQL time field, you currently need to specify values in selectors in full "H:MM:SS" format. So if you wanted to get all events starting on or after 9am you'd do something like this... $events = $pages->find("template=events, starts>=9:00:00")->sort("starts"); This is definitely a beta module as I've not tested every single input format yet. Currently does not support negative time-periods or fractions of a second. FieldtypeTime on Github FieldtypeTime in the Module Repository Releases Version 0.2.0: Adds support for the use of this input field in repeaters and repeater matrix types. Version 0.1.0: Adds clock picker.

Yes, I posted that as an issue on github - feel free to add a +1 over there to see if Ryan will bump its priority.

Posting on the run but something similar was asked recently. You may find some clues there.

Those are a couple of good questions - with the new core upgrade module I've started setting the dirs on my development boxes as 777 just to allow easy updates as the dev branch gets commits but I won't be doing that on production machines. I wrote the rule about making the site folder unwriteable by the webserver process in case someone managed to craft an attack against PW that tried to write to the file system; I'd prefer that such an injection/scripting attack - if found - would not be able to write to the disk. So that's definitely a me thing rather than an official PW rule. To try and anwser your question about how to set it - well, it depends on a few things... Going with 0550 means the owning user (the first 5) gets read and traversal rights, the next 5 means users in the owning group get read and traversal rights and the final 0 means other users get no rights. This is the most secure setting but requires that the user the webserver process runs as be either the owning user or a member of the owning group. Going with 0750 (owning user can write to the tree) would be better if the owning user were different from the webserver user and if the webserver user were a member of the owning group. Going with 0755 (owning user can write the tree and any user can read & traverse) would be the one to go for if the owning user were different from the webserver user and if the webserver user were not a member of the owning group. In this respect, this option is the most universally applicable but it allows anyone on the box the right to read and traverse into your file structure and, on a shared host this is a security risk as they can then possibly do things like read your config file - with your DB access credentials in it - if that has read permissions for other users too! If you are on a VPS with no shared accounts - then this setting is fine. To find out the user and group ownership you'd do an "ls -l" from a linux command line and it should show you the owning user and group names. The diagnostic module works by checking if the directory is writeable by the user the webserver process is running as; it doesn't try to analyse or recommend how to fix it (if I remember correctly.)

What do you get if you type umask<return> from a command line window on your server box? Edited to add: Sounds like it will be '0022'.

Well, the only place I can really think of is from your config.php file - but in that case you might as well just put your spl_autoload_register() directly in there. Should be safe from core upgrades too.

Hi @Gazley, have you tried a before hook on session::init() ?

How about this (untested)... $categories = $page->children; /** * This will hold unique values from the possible repeats in your page tree... */ $uniques = array(); /** * Iterate as you did before but only keep one copy of each category you visit. */ foreach ($categories as $category) { $categoryNames = $category->categories; foreach ($categoryNames as $categoryName) { $uniques[$categoryName->id] = $categoryName->title; } } /** * Now do what you want with the uniques. They are indexed by page id. */ foreach ($uniques as $id => $title) { echo $title, "<br />\n"; } ...?

Amazing, how did I miss this!

@charger Have you considered just keeping everything in a single currency and using something like Ryan's currency conversion module to create other currency prices on-the-fly as needed?

@adrian Thanks! Good to know I'm not the only one who likes names well formatted. @apeisa Thanks Antti. Actually, the sanitiser is already a stand-alone PHP class. The package being sold on QBox.co includes a PW Textformatter which makes it really easy to use in your PW projects.

Please note: This post refers to a commercial package for PHP that includes a module for ProcessWire. If you have to deal with name data on a day-to-day basis then you know what a mess people can make of typing names. If your business prides itself on good formatting – for stationary, labels, email or nametags – then the English Name Sanitiser package for PHP & Processwire can help you keep things well formatted. Background About five years ago I got involved with selling books online via various storefronts such as Amazon, Play, Abebooks and Alibris. Day after day we'd get orders from customers and, quite frankly, the formatting of the Ship-to name field was a mess. A big mess. Some people typed "jenny smith", others "JANE DOE", some "jASON yARDLEY" and still others would write "No invoice" after their name. A few actually formatted their names right. As a business that prided itself on neat formatting of our postage labels - and because dealing with customers and the local post-office about missing parcels is a pain - I decided to start sanitising incoming names to not only make them look good to the customer when they received them but also to make the names and addresses as clearly and unambiguously readable as possible for postal workers. I initially thought that it would be an easy problem to fix - just run each name through mb_convert_case() but it turned out to be a more difficult than anticipated as PHP's methods of converting case handles several situations in a pretty unsatisfactory manner; names like McGregor or O'Donnel, company names and names with missing spaces following punctuation ("john h.jones" etc.) Here's a quick comparison of how PHP and the NameSanitiser do with some problem names... (The whole list is available under the "Tell Me More" button on QBox.co) Over four years later I've decided to release the English Name Sanitiser as a commercial offering that makes it easy to format English names (it includes a PW Textformatter.) The package itself includes a stand-alone sanitisation file that you can use in other PHP projects so it is in no way limited to just PW installations. Licenses are available for individual sites, developers or agencies/institutions and, as I still sell books via Amazon and use this package in my sales system, it is being actively maintained. Visit QBox.co now to learn more.

@Tom, I just tried this on my https site and the automatic PW redirect doesn't seem to be working so I've opened an issue on github for the problem. In the meantime, you could try this in the top of your template files... if (!$config->https) { $session->redirect($your_https_landing_url); } Just build the landing url as you want or use the current url and substitute the https scheme.

Actually, you can do this from within PW itself without resorting to htaccess rewrites (if you want to.) Edit your templates and look at the URLs tab. There is a section there where you can define which scheme the page should be served as. Switch over each template representing pages that you need served via https and save them. Your pages should now be directly accessible via the https scheme and if you try to access them via http you should be redirected to https.

Anybody seeing any weirdness in 2.5+ with tabs added to the page edit forms by either Nik's PageReference module or Soma's Template Notes module? The fieldset in the tabs those modules add to the page form seem to always migrate below the save button. Like this... Doesn't matter if its the legacy theme or Tom's new theme. I don't ever remember these modules having a problem prior to 2.5 -- but I've not tried them in ages.