netcarver

Thanks for posting the link to recurr - looks like another interesting library. I should have posted the link to the development branch of the when library. Most of the documentation is done by example in the tests subfolder. Minutely recurrence is handled, check out the second example here. Let me know which library works out better for you as I'll be needing one of these myself really soon.

@gebeer I'd steer towards the page field option above or go with a custom DB table handled by a module. Anyway, I'm not sure you have to be constrained to a full-text search selector. Is there some constraint on this project that's forcing you to use fulltext fields for some reason? I think you can arrange to do things with a normal "equals" selector (which is probably a lot faster) though it might require some more setup. It would be good to benchmark the solution you are using with the ad_publish field as a text field and doing the fulltext-search in the selector and then comparing it to something like this (untested)... Create a timestamp field called "publish_at" and a page field called "advert_id" which is setup to a single value or null in the config page. Create a template called publishing_schedule and add both the "publish_at" and "advert_id" fields to it. Create a parent page called "Publishing Schedule" in your page tree somewhere (it can use the basic-page template) and set up its children to use the publishing_schedule template. Setup a page save hook so that when you save an advert (where you specify your start date + time, end date + time, frequency etc) you then calculate your publishing timestamps using existing code or the when library and, for each timestamp, you'd create a new page under the "Publishing Schedule" parent page using the "publishing_shedule" template. Set the publish_at and advert_id fields as required and save the page. You should now be able to find all ads published on a particular timestamp with a simple query like... $published_at = $pages->find("template=publishing_schedule, published_at=$timestamp"); foreach ($published_at as $published) { $advert = $published->advert_id; /** * Access your advert fields as needed. */ echo $advert->title; // etc } You could then benchmark which one worked better for you.

@kongondo, I like the thinking but you never know when an extra X will get added to a size; particularly medium. In other words, I suspect the table would need to accept changes in either dimension. How about simply concatenating the x and y variable to give a key that can then have a simple value stored against it? So you'd end up with a table that had an indexed product page id, an indexed "key" and an "amount" column. The function to make the key would just do something like... function makeKey($size, $variation) { $size = wire()->sanitizer->name($size); $variation = wire()->sanitizer->name($variation); $key = "$size/$variation"; return $key; }

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