Leaderboard

I released a simple module: Processwire Dice Captcha Module This is a very simple captcha module. For more extensive information please read the REAMDE on github. If you want you can change the jpg files and adapt the size setting in the module accordingly. This should also increase security as if you use more complex images they will be harder to recognize. You can als change the number of dices asked for. Usage: <?php //Init Module $dice = $modules->get("FormDiceCaptcha"); //On submit check if the validation is correct if($input->post->submit) { //validate - the value is stored in the session if(!$dice->validate($input->post->captcha)) echo "<p class='error'>".__("Please check that you have completed all fields")."</p>"; else echo "Success!"; } ?> <form method="post" action="./"> <!--Show captcha --> <img src="$dice->captcha()"/> How much is the sum of the dices? <!--ask for sum --> <input type="text" name="captcha" value="$form[captcha]"/> <input type="submit" name="submit" value="submit"> </form> Github: https://github.com/romanseidl/FormDiceCaptcha Changelog 0.1.1 Changed the directory structure to conform with Processwire standards and renamed the module classname to FormDiceCapture to conform naming conventions. Also the github project had to be renamed. In case you have version 0.1.0 installed you will have to change the calls to $modules->get('DiceCaptcha') to $modules->get('FormDiceCaptcha') after updating to 0.1.1.

I had the common css problem of not beeing able to format a link by its children. Thus I ended up producing a very simple Textformater: TextformatterImageLinkInterceptor Processwire Image Link Interceptor Module @copyright 2015, Roman Seidl based on HTML Image Interceptor Textformatter @copyright 2013, Martijn Geerts Licensed under GNU/GPL v2, see LICENSE.TXT This module simply adds a class to all images that ae contained in a link as the first child. Thus the following: <a href="/"> <img src="/site/assets/files/1/hansi.jpg" alt="Hansi"> </a> Should be filtered to be: <a class="imglink" href="/"> <img src="/site/assets/files/1/hansi.jpg" alt="Hansi"> </a> Github: https://github.com/romanseidl/TextformatterImageLinkInterceptor/blob/master/README.md Changelog 0.1.1 Changed the directory layout to conform with Processwire module standards. To do so, the github repository had to be renamed.

I just pushed an update to the module that corrects the issue. This module used a naming format for a file that's not compatible with PW 2.5.11+ (though sounds like it still may have worked up until the latest, but really shouldn't have). If you grab the latest it should work now.

I found out that the modue is not set to singular in the module header: static public function getModuleInfo() { return array( 'title' => 'Page Image Manipulator', 'version' => 14, 'summary' => 'This module provide basic Imagemanipulations for Pageimages and Imagefiles', 'author' => 'horst', 'href' => 'http://mods.pw/5E', 'singular' => false, 'autoload' => true ); } But because of this init gets called again and again: public function init() { $this->addHook('Pageimage::pimLoad', $this, 'getPageImageManipulator'); $this->addHook('Pageimage::isVariation', $this, 'HookIsVariationPim'); } Funny enough it gets called with every call to a "pimLoad" initiated by a hook. Thus the hooks mulitply causing the module to crash (timeout exceeded) after 7 to 10 images beeing processed in a row within a single page. I set the module to singular and everything seems to work fine.

I produced a module that: backups the db zips the site uploads the zip to google drive The module is not ready for publication yet as it has to be tested more thouroughly and the code has to be revised first. There is a question tha arised in the making of the module: Is there a documentation of the standard procedure on how to backup a site? I just used: WireDatabaseBackup wireZipFile to do so. I had to figure out which directories to include and whicht to omit. As I looked into exisitng modules I came accross "Site Profile Exporter". This one claims to produce a site profile which is easily reinstallable. I am not aware if this is really the case as the module is from 2012. But the ideas seems promising. Is this idea still existing? And if so is it documented? I could not really understand what "Site Profile Exporter" is doing as it is a bit of a mess in mixing presentation and business logic. Call me a middleware developer lost in a php publishing system but still I hate when people zip something in between of creating a form.

Hi, We've just landed a nice project with member functionality and we are looking to outsource some work. The skills we are looking for are: Good communication skills At least medior ProcessWire knowlegde (you should be able to build a module) Good understanding of AJAX (you should be able to build small forms and post them with AJAX) Good insight in member based/interaction application development Basic front-end development The development work can be done in English, but please note that the actual system in going to be in the Dutch language (since we first start in English this shouldn't be a problem) Work done here: UX Visual design ProcessWire configuration (i.e. templates/fields/structure) CSS styling Work done by you: Build the application on the front-end with minimal styling but in accordance with the layout (unsemantic layout framework). Build the forms and process the data with the great ProcessWire API Build an AJAX based filter system (example in Dutch) Build a simple subscription layer on top of the application (like Quora, basic functionality is visible to all, extended functionality only to members). Each member role will have additional subscription options which will have to be paid (using Mollie > great API) (this can be done later if we don't have time right now) Save all the processed data to simple text based log files ($log API variable) (this can be done later if we don't have time right now) My estimate that there will be around 40-70 hours of work to be done in PHP. Most of this will have to be done before 1 May. If it's possible you can start earlier please let me know. I know that is tight, but we have a decent budget. If you are interested please let me know. If you are interested please sent me some work you have done plus your hour-rate in a PM. After the initial contact we can setup a chat or Skype call and discuss the project further (both estimate and billing stuff). Thanks!

And 7. Because 7 "ate" 9.

Until the core issue is fixed properly, simply wrap that entire function in: if (!function_exists('PageEditFieldPermissionConfig')) { That will get things working again for you.

Ok great. I was not 100% sure if setting it to "single" would be the perfect solution as I'm still not too familiar with the module architecture. But it seems reasonable to me, and if it also seems reasonable to you then its fine. At least it works fine for me even when scaling 50 images in a row for a automatically generated slideshow. Thanks for the plugin, it produces way better results than the standard image plugin in terms of quality. BTW: I needed centred scaled down images that are not cropped and keep their proportions. Thus I had to add the following code: function galleryimage($image) { if(($image->width / $image->height) > (600 / 400)) return $image->pimLoad("gallery")->width(600)->canvas(600,400)->pimSave(); else $img = $image->pimLoad("gallery")->height(400)->canvas(600,400)->pimSave(); } Maybe you could add an option to scale that allows to keep proportions that way as this is something others might need too. Actually this task was the reason for me to choose pim as this is not done correctly by the standard scaling algorithm, it seems to produce images that are not centred when you add an image that has the correct width but not the correct height. So when calling this with an image of e.g. 600x300 i would get a reulting image where all the added vertical canvas is on the bottom or if i remeber correctly it just returned the orignal image even though it was of the wrong size. return $image->size(600, 400, array( 'upscaling' => true, 'cropping' => false, 'quality' => 97 )); But thats something for the core module developers maybe.

, many thanks! This is fixed now in the Github repo.

Often times, creating a side project is first and foremost scratching your own itch Or to start differently: Currently, I'm developing a site where I need CKeditor (and later jQueryUI Datepicker) outside of the admin, in frontend. I searched Google and the forums and found an approach to follow - but during the research the site laravel-recipes.com came into my mind (since I'm currently also looking into this framework). It's content consists of small, spot-on bits of information, for example: http://laravel-recipes.com/recipes/269 Just to think out loudly here, wouldn't it be nice to have a ProcessWire counterpart of such a site? processwire-recipes.com for example? Target group: Developers, from beginner to advanced Difference to these forums: Stripping the discussion part, concentrating on the info; and if done properly: bypassing the mediocre forum search, better tagging Difference to the official tutorial section: Focusing on not creating a whole site, but modular parts of it. Single solutions. For example: First child redirects (shameless plug, but this is the format of information pieces I'm having in mind) Difference to the API documentation: Situation-based ("I need this and that") instead of architecture-based Laravel.io (forum), laravel.com (official, and doc) and laravel-recipies.com possibly prove that these type of sites can coexist in a framework ecosystem, so I guess a recipes site would not cannibalize this forum here nor the doc section. A recipe site like this would live and die with its content, of course. I would be ready to share all the small pieces of information I encounter that would make a good "recipe". But that alone wouldn't be enough so this project won't survive without contribution of the community. What's your opinion on this? Yea or nay? Update: ...it just took, erm, nearly three months,... but here it is: https://processwire-recipes.com/

ProcessWire LazyCron Module This core module provides hooks that are automatically executed at various intervals. It is called 'lazy' because it's triggered by a pageview, so the interval is guaranteed to be at least the time requested (and maybe more) rather than exactly the time requested. The more pageviews your site gets, the closer it is. This is fine for most cases, but if you need it to be fully accurate I'll describe how you can make it not-lazy a little further down. How to download and install This was built as a core module for ProcessWire 2.1 (development version), so you need to grab the latest commit of the development version and you will have the module. This module is not compatible with PW 2.0 (stable version). ProcessWire 2.1 is at: https://github.com/ryancramerdesign/P21 If you already have the latest commit of ProcessWire 2.1, go to your modules menu, click "check for new modules" at the bottom, and then click the "install" button for the LazyCron module. LazyCron is now installed and ready to be used by other modules or via the API. Hookable time intervals These are the function names you can hook from LazyCron. The function names describe the time intervals they provide. If you think I'm missing any important time intervals, please let me know and I can add more. every30Seconds everyMinute every2Minutes every3Minutes every4Minutes every5Minutes every10Minutes every15Minutes every30Minutes every45Minutes everyHour every2Hours every4Hours every6Hours every12Hours everyDay every2Days every4Days everyWeek every2Weeks every4Weeks How to use it This module is mainly of use inside the API and to other modules. You hook one of the named intervals mentioned in the list above, and the function you provide will be executed at approximately that time interval. Here's how you do it, both from a class (module) and outside of one: Usage in a class/module <?php // initialize the hook in your AutoLoad module public function init() { $this->addHook('LazyCron::every30Minutes', $this, 'myFunc'); } // the function you want executed every 30 minutes public function myFunc(HookEvent $e) { echo "30 Minutes have passed!"; } Procedural usage (like in a template or elsewhere in the API): <?php // create your hook function function myHook(HookEvent $e) { echo "30 Minutes have passed!"; } // add a hook to your function: wire()->addHook('LazyCron::every30Minutes', null, 'myFunc'); Arguments provided to the hooks If desired, you can retrieve the number of seconds that have actually elapsed since your hooked function was last called: <?php function myHook(HookEvent $e) { $seconds = $e->arguments[0]; echo "30 Minutes have passed! (actual seconds were: $seconds)"; } Note that in production usage, you probably wouldn't want to echo anything from these hooks because they are executed after the pageview was already delivered. So while you can directly echo output from these, it's probably not that useful (other than for demonstration purposes, like this). How it works When installed, LazyCron hooks into ProcessWire's ProcessPageView::finished() method. This ensures that the scheduled tasks are executed after the pageview has already been delivered rather than before or during it. This hopefully avoids any perceived slowdown if the scheduled tasks take time. LazyCron provides a bunch of hooks that anything else can hook into. These functions are outlined in the section above titled "Hookable time intervals." These functions are called at the interval specified in their name. LazyCron simply uses ProcessWire's existing hook system. So when you hook into any one of these functions, your hook will also be executed at that same time interval. LazyCron hooks are only executed during pageviews that are delivered by ProcessWire. They are not executed when using ProcessWire's API from other scripts. How to make it not-lazy In most cases, the way that LazyCron works out of the box is just fine. But if your need requires assurance that the module will always execute at exactly the interval you need (rather than possibly later), you need to setup a real cron job to trigger a pageview in your site. So if you needed accuracy to 1 minute, you'd setup a cron job to execute every one minute, and pull a page from the site. There are any number of ways you could pull a page from your site, but here is one using wget: wget --quiet --no-cache -O - http://www.your-site.com > /dev/null That command basically says to pull a page from the site, don't tell us anything, don't cache the request, and discard any output.

Ha! that did it!!! Thanks for the help with that! Creating an issue on your github page for the Reno theme.

I just opened an issue on this module. It is very useful in a variety of circumstances.

Numbers aren't that harmful except 007

Hi, new version is here, as I promised. It's currently on the dev branch: https://github.com/uiii/ProcessWire-FieldtypePDF/tree/dev. The readme is updated so everything should be clear. It contains tests and they successfully passed for PW 2.4, 2.5. If you can try the module, I'd be glad to hear your opinions and suggestions.

Some threads worth reading if you haven't already seen them: https://processwire.com/talk/topic/5777-default-value-for-fields-in-admin/ https://processwire.com/talk/topic/1593-how-can-i-specify-default-value-for-certain-input-field/ https://processwire.com/talk/topic/394-default-field-value/

That's why all of us suggest doing updates on dev environments. If there are problems just wait till they are sorted out. Just do not update live sites and expect it to work every time. Additionally it's still the development version that most of us use, so it's natural that problems can arise, but if so report them and sooner or later they will be sorted out. As said before there's currently no need to update for other reasons than access to new features. Regarding userinputs: Sanitizing them is what you need to do no matter which cms you use. As soon as you do implement functions where users can directly input data you need to make sure it's not harmful data. So if you're for example using the core comments systems that's already implemented, but with ProcessWire's nature of encouraging to build own systems you need to be aware of the potential of malicious input from users. For example anywhere you accept data from forms or from parts of the url you need to consider that a user could abuse those points of access to inject own logic.

Hi rot - thanks for this. Might I make a small suggestion. You might find it simpler to use DomDocument - something like this: $p = $pages->get(1); $dom = new DOMDocument(); @$dom->loadHTML( mb_convert_encoding($p->body, 'HTML-ENTITIES', "UTF-8") ); $dom->preserveWhiteSpace = false; $images = $dom->getElementsByTagName('img'); foreach ($images as $image) { // the existing classes already on the images $existing_classes = $image->getAttribute('class'); // the class we're adding $new_class = ' this-will-be-the-class'; // the existing classes plus the new class $class_names_to_add = $existing_classes . $new_class; // add class to the parent of the img node - <a> $image->parentNode->setAttribute('class', $class_names_to_add); } In this example I am applying it to the body field of the homepage, but you get the idea

You're missing the mandatory sleepValue() and wakeupValue() functions. These are responsable for makeing the objects data available to the database functions and for combining the data from the database to the field object.

Nope, LanguageTabs are a different kind of animal. The fieldsets mentioned are WireTabs.

There's no build-in mechanism to do what you want I guess. The easiest route I see is with AdminCustomFiles. I would install that module, check the checkbox for config data. Then build your logic with the config.AdminCustomFiles object.

Hey kongondo, thanks for the suggestion - already on my list of things to do I would like to be able support Fieldset tabs as well as custom ones created via modules, like Nic's Page References Tab - I can see I am going to need more than one technique here Was there any particular custom tab setup you were interested in being able to hide? Just good to get an idea of all the possible options. Thanks!

Beautiful work. I like the cleanliness of the site. Very well done.

@en4ce, thanks for getting ProCache. I am guessing that your order was placed under a different account than the one you are logged in with now, because there's no order connected at present. If you can send me a PM or email (ryan@processwire.com) with your key and any order information you received, I can connect it with your account and get you setup asap. Thanks.

Please do first look at the Edit part. I seems like the script adds the alternative "0" as value for unchecked checkboxes to the checked ones as well. Could you please add the consoleLog statement in the inputfields.js: if(($field.attr('type') == 'checkbox' || $field.attr('type') == 'radio') && !$field.is(":checked")) { // @todo this part will no longer work with multi-checkbox/radio fields consoleLog("*** Added 0 as alternative ***"); values[1] = '0'; } If this prints the line for both unchecked and checked states than we at least know where it's not working correctly. Edit: Looking at your logs again, maybe this isn't the issue, but more likely the checkbox returning a value of 1 even if it's unchecked. Could you also please test if this lines are correctly setting value to null. // value of the dependency field we are checking (if not already populated above) if (value === null) { if($field.attr('type') == 'checkbox') { value = $field.is(":checked") ? $field.val() : null; } else { value = $field.val(); } }

To make this fully clear. The implode function you're using is a ProcessWire specific implementation of the php function. The php version does only work on arrays and the array has to be passed into the function as parameter. What you're using is a method of the WireArray class, which mimics a lot of the array features, but adds lot more to it. That's why the syntax is different and therefore the php docs wouldn't help to much.

$mr = wire('user')->user_mr; return $pages->find("has_parent=$mr"); Your code works for me as is...maybe you have a typo somewhere?

Thx for this Adrian. Would it be able to work with custom tabs?

There are currently no known security issues in any version of PW, but I still like to update because of all the new toys (https://processwire.com/blog/) and bug fixes. Personally I like updating via git pull, but this module also makes it super easy: http://modules.processwire.com/modules/process-wire-upgrade/ Enjoy the ride

Another significant update which should be a huge timesaver. You can now populate all the text/numeric fields on newly created child pages (Add & Overwrite modes) from CSV formatted rows. This allows easy creation and population of all page content, for example you could populate an entire page tree of country details by pasting in CSV formatted content like: "Bolivia, Plurinational State of",BO,"BOLIVIA, PLURINATIONAL STATE OF",BOL,68 "Bonaire, Saint Eustatius and Saba",BQ,"BONAIRE, SAINT EUSTATIUS AND SABA",BES,535 etc etc Hope you guys will find this as useful as I am As always, let me know if you have any problems or suggestions for improvements!

Everybody who has import scripts running as a cronjob, there's this effect that the cronjob is run als guest user. So imported pages via API are created and modified by "guest". This is not nice and can lead to confusion. "What?! How can a guest create this page?" To avoid this and set the current user via API you can do this at the beginning after bootstrapping PW: include_once("./index.php"); /** * Overwrite static user for imports. All created pages will now * have created and modified user set to "importer" PW user. * Otherwise API created pages will have the created user "guest" * ------------------------------------------------------------------------------------- */ $importerUser = wire("users")->get("importer"); if($importerUser->id) wire()->setFuel("user", $importerUser, $lock = true); Only thing is you have to create a new superuser with the name you wish to use for such scripts and replace the name in the script. Now if you run this script no matter from where or with what current user you'll have "importer" as the created and modified user. ----- Note: There's a new way to set system vars like $user via wire(name, value), but this doesn't seem to work in this case in my tests. Cause the user will get overwritten again when creating a page by the current user calling the script. I'm not sure it's a bug or what, so it might be possible in future to use the shorter version of wire()->setFuel(name, value).

I never would get the email from the adminEmail address so I just added $form->email = ('email@example.com'); $form->template = wire('templates')->get('contact-form'); // required $form->requiredFields = $formRequiredElements; $form->email = ('mont@exampledomain.com'); // $form->email = wire('config')->adminEmail; // optional, sends form as email $form->parent = wire('page'); // optional, saves form as page $content .= $form->render(); // draw form or process submitted form

Hi Christophe, Please refer `site/templates/_functions.inc` file. Inside of that file there is a method named `getContactUsForm()`. At the moment `from email address` would be your admin email address. Please feel free to modify it in `getContactUsForm()` method. Thanks

hi manaus try this $u = new User(); $u->of(false); $u->name = $name; $u->email = $email $u->pass = $password; $u->addRole("UserRole"); $u->save(); $u->of(true); you can read here http://processwire.com/talk/topic/3543-register-users-and-add-page-same-as-username/#entry34822

If you use PW form API, it will get validated if you call processInput() $form->processInput($input->post); I think the CSRF doesn't get reset if the CSRF was valid, but you can do it manually with $session->CSRF->resetToken(); after validating the form. Or if you do manual form and not use InputfieldForm you can generate and validate the token $session->CSRF->validate(); // will throw exeption if invalid And get the token name and value with it respective methods $session->CSRF->getTokenName(); // name for input hidden $session->CSRF->getTokenValue(); // token value Also the trick renobird mentioned is also very good to prevent double click submission errors. Of course you can still use redirect method and as you may found the $notices errors and messages are transported through redirects.

I implement the PW CSRF token in my forms so a resubmit will result in a error message.

Technically the only module groups built-in are those that start from a base class: Process, Inputfield, Fieldtype, Textformatter, ModuleJS. The headlines you see in the Modules list are runtime grouping of the first word in a modules' class name. Conveniently, this works with our our base-class module groups, but it does also extend to other modules with similar naming conventions. For the most part, I think it's better not to use one of the base class names for your module unless it extends that class. In the future, we may want to offer other types of runtime grouping options like: modules related by dependency, autoload modules, etc. Related modules in a group may have different naming conventions by need (like a related module set that has it's own Process module, Fieldtype and perhaps others) -- these aren't expected to appear together in the modules list.