Leaderboard

TextformatterCurrency A locale-aware currency formatter module for ProcessWire. The module reads a formatted string, splits it and formats each valid monetary amount according to the locale defined in the module settings. The module is capable of using the visiting browser's headers to determine which locale to use when formatting monetary amounts of various currencies. Internally, the module uses PHPs Internationalization extension (intl) to do the formatting. Input money format The input money format is made up of any number of currency-amount pairs. Each input money pair is made up of 3-letter ISO 4217 currency code and a numeric amount. These are always separated by at least one space with the code coming first. (eg. "GBP 50.99" or "JPY 100000") No thousands separators are allowed in the input. A full-stop '.' character is the only acceptable decimal separator. Each money pair is separated by a configurable character string ('|' by default.) You can change the character used to split the incoming string into currency-amount pairs in the module settings page. Output format Each currency-amount pair is formatted using the defined locale or that supplied by the browser and thus appears localised in the output of the formatter. If the input text has more than one currency-amount money pair then the formatter will join the localised outputs for each pair using the output glue string defined in the module settings. Negative amounts are prettified by substituting ascii '-' characters with the more typographically pleasing minus glyph '−'. Examples Using Module Defaults Input "GBP 50.99 | EUR 100" gives "£50.99 + €100.00" when viewed in browser set to British English but gives "50,99 £GB + 100,00 €" using a browser set to French. Availability On github. In the module repository, here.

Maybe you should wait for my Nette forms module indeed. Seem like I don't manage to hide it forever It's functional and I use it on many production site but given the complexity of forms it's still only in alpha state. It's more about how I solved integrating Nette forms into PW, but still, there are areas I haven't explored.

Thanks Macrura...had let this slip under the radar. I'll add it as an option so users get to choose (and why wouldn't they?) if they want the textarea formatted with ace or not...

I added this small tweak to the FieldType, which allows me to use the Ace extended for my code editing.. if(wire('modules')->get('InputfieldAceExtended')) { $f = $this->modules->get('InputfieldAceExtended'); $f->mode = "php"; $f->theme = "monokai"; } else { $f = $this->modules->get('InputfieldTextarea'); }

No, there is only one field per image: foreach($page->images as $image) { echo '<img src="' . $image->width(200,0)->url . '">'; echo '<p>' . $image->description . '</p>'; }

With debug mode enabled, clicking the debug action/icon shows the debug tools in a panel - but only for a Superuser. So the icon should not be visible for non-Super users.

Done: Issue #1828

If you are using a web analytics package (Google Analytics, Woopra, Piwik, etc..) you will see what was typed by the user. I did a quick check with Piwik to confirm this is true. Initial Search on website Search completed (searched word not found) Piwik search results

$image->description But since you wrote 2 text fields, not one, it's not really an alternative. And the description field is for... well, for image description I would use Image Extra, or the other profields mentioned above. http://modules.processwire.com/modules/image-extra/

You can use module Image Extra or the pro field Matrix Repeater or Table field. Or page table, but that's not so comfortable.

Just spotted this in a post by Ryan (here); Although my own use-case for this module is for an invoicing system that is not publicly accessible - I can see that this might be the case if this is used on public facing PW pages. Unless anyone can suggest a better way, I'll look at adding a method to allow the locale to be set after the module is loaded (either from a template file or perhaps ready.php.) This should allow a site to control its own URL-to-locale mapping and still use this module as a textformatter if desired.

I am seeing this too - would you mind posting an issue on Github please? In case others reading this are confused - it's the new icon in the breadcrumb trail that ottogal is referring to.

If you have updated to 3.0.18 just before the error occures, you also may try to empty the modules cache 1-3 times.

Thanks for your response. However the request gets redirected before even touching PW functions. Writing a die() instruction at the top of the ___processInput() function in InputfieldFile.module doesn't change a bit. I'm thinking that this problem is related somehow to the hosting provider and some obscure Apache directive. Non-ajax uploads work correctly.

Any chance you have: $config->moduleCompile = false; in your config.php file?

Thanks; it's helpful anyway. I only had gc_probability, so maybe this will help.

Is not 100% to your request, but maybe of interest too. https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/

There is also if (! Quick research via Google: For example, take a look at the current last answer here : http://stackoverflow.com/questions/6311040/php-if-not-equal-and-or-issue-why-doesnt-this-work (one example with || and one example with &&).

Netcarver beat me An alternative: <?php if ($page->matches('id!=1021|1105')) { echo 'do stuff'; }

Just to add that here. The driver can be installed manually until and if the pr does get merged into valet. Just put the ProcessWireValetDriver.php of the pr into the ~/.valet/Drivers folder and start your ProcessWire project.

Is this already in, "crop sizes from presets"? If we could have that with the core images field, it would make the croppable images obsolete, what I think would make things much easier. We only would need one images fieldtype and optionally can define "presets" or not. Wouldn't it? +1

I haven't gone that far and I really hope I never need to

Just changing the markup elements wasn't flexible enough for my usecase and manually putting all those form parts in their wrapper markup isn't a option as well, as the form is dynamically adjusted to which data the current user does need to supply (by role and such things). That's why I went with the custom renderer class. Just doing a 'echo $form' does render the complete form with markup just as I need it to be.

I do not use PW's form markup at all but Nette Form elements. Renderer is easy to customize, eg. $required_asterix = Html::el('sup')->setClass('asterix')->setText('*'); $colon = Html::el('span')->setClass('colon')->setText(':'); $renderer->wrappers['form']['container'] = 'div class="form-wrapper"'; $renderer->wrappers['controls']['container'] = 'div'; $renderer->wrappers['control']['container'] = 'div'; $renderer->wrappers['control']['description'] = 'p class="form-description"'; $renderer->wrappers['error']['container'] = 'ul class="help-block text-danger form-error"'; $renderer->wrappers['label']['suffix'] = $colon; $renderer->wrappers['label']['requiredsuffix'] = $required_asterix; As I wrote modifying the markup this way is well enough for simpler forms, and even for larger forms if there are no fancy things. Here is a quick screencap where I used manual rendering, which allows custom markup. Form fields are defined separately, and you can retrieve the full control, or only the label or control, error parts, etc. I like the freedom it gives. <div class="form-wrapper" n:if="$rsvpForm"> <fieldset> <legend><span><strong>Personal data</strong></span></legend> <p class="checkbox-wrap"> {$rsvpForm[participation_toggle]->getControlPart()} <label for="cf_participation_toggle">We attend the wedding</label> <span class="slideToggle">{$rsvpForm[participation_toggle]->getLabelPart()}<strong></strong></span> <label for="cf_participation_toggle">Unfotunately we cannot attend the wedding</label> </p> <div id="personal_data"> <div> <div class="input-wrap">{$rsvpForm['name']->control->cols(35)} {$rsvpForm['name']->error}</div> <div class="input-wrap">{$rsvpForm['email']->control->cols(35)} {$rsvpForm['email']->error}</div> <div class="input-wrap">{$rsvpForm['phone']->control->cols(35)} {$rsvpForm['phone']->error}</div> </div> </div> </fieldset> ...

@Jonathan: You have covered "Data Migration", but does it include "site migration" too? Sure, normally it is a straightforward process, however you might want to demonstrate it as well, just to contrast it to the complete WordPress migration process. For example I have my own Bash script (utilizing wp-cli among other built in Linux tools) for migrating WordPress sites and probably it is also possible to implement something similar with Wireshell. I'm not saying that you should spend too much time on the issue of site migration and Wireshell, and you might have already cover the issue of complete site migration in one of the episodes, still if not, you might want to dedicate a few minutes to it. Otherwise you presented such a thorough list of everyday issues that it is hard to recommend something else to add to it. I can't wait either! Thanks in advance!

Better late than never. I'm almost done with my WordPress vs. ProcessWire series. I have about ~8 videos left to make. I will be uploading all the videos to YouTube in a playlist. Need a couple more weeks to finish them off and add a little polish. Here are the videos in the series (not yet in the final order): Installation Pages Page Templates Custom Fields Custom Post Types Blog Documentation API Updates Client Help Plugins Forms Shortcodes Page Order Images Videos Themes Widgets Menus Global Settings and Options Page Caching Search Engine Optimization XML Sitemaps JSON Data Search Users and Roles Config File Multi-Language Data Migration Ecommerce Community Comments Revisions Admin Themes Command Line Interface Hosting Multisite Admin Section Performance Visual / WYSIWYG Editor Bootstrapping Admin Bar Composer Debugging Front-end Editing Page Builders Each video is about 3-10 minutes long and compares a feature in WordPress with the same or analogous feature ProcessWire quickly and concisely. For example, Shortcodes vs. HannaCode, Gravity Forms vs. FormBuilder, WP-CLI vs. Wireshell, WP Rocket vs. ProCache, WP's Menu Builder vs. Menu Builder, etc. Some are a little more in-depth than others. I do give WordPress a fair shake, try to remain objective and let ProcessWire's superior approach to features speak for itself. I will most likely be adding an intro video that explains the series as well with some background as to why I use ProcessWire instead of WordPress and the philosophical differences between the two. The goal is to get people, particularly advanced developers and web firms who know how to code and who are on the fence about switching to a new CMS, to quickly see all the analogous features that they are used to in WordPress done in ProcessWire. Hopefully they will get the warm and fuzzy feeling and explore our community further. If there are any topics you feel that I have missed, please let me know. Make sure the topic is specific enough to warrant a video of its own, as this series is a feature-to-feature comparison. Thanks

Welcome to the forums! The $user variable is already taken in the globally accessible wire/fuel object, so don't use that. from your module you can set the var as follows (in your before page render hook): $this->wire->set('foo', 'bar'); in your template you can call it like any other wire/fuel variable (like $user, $page, $session etc), since the they are passed to templates automatically: echo $foo; // 'bar' More on THE fuel/wire: https://processwire.com/talk/topic/3876-using-fuel/ Soma:

It would be with the complete path $page->template->filename = $config->paths->templates . 'summary.php'; $page->render();

This is the way to create template and fields with API: // new fieldgroup $fg = new Fieldgroup(); $fg->name = 'new-template'; $fg->add($this->fields->get('title')); // needed title field $fg->save(); // new template using the fieldgroup $t = new Template(); $t->name = 'new-template'; $t->fieldgroup = $fg; // add the fieldgroup $t->noChildren = 1; $t->save(); // add one more field, attributes depending on fieldtype $f = new Field(); // create new field object $f->type = $this->modules->get("FieldtypeFloat"); // get a field type $f->name = 'price'; $f->precision = 2; $f->label = 'Price of the product'; $f->save(); // save the field $fg->add($f); // add field to fieldgroup $fg->save(); // save fieldgroup All pretty much standard OO one can figure out looking at core and PW modules. But not someone unexperienced would figure out by themself. I think at some point we need to cover these in a documentation.

The field wasn't really designed for that particular use, so there currently aren't instructions on how to do that, but it's certainly possible (and probably not too difficult). But there isn't any easy answer to this question short of modifying the existing Fieldtype/Inputfield or creating a new one that extends it. I imagine that we'll have this built in eventually.