Leaderboard

That looks great davo! Would you mind giving some feedback about the hard parts that you had to do, or any special cases or tips you might share? We're on the last leg of doing the same thing, but with android applications on the frontend. We've built a fully customizable loyalty/rewards web application that serves as the backend for the terminal application (an android POS device with nfc reader) that sends all the transactions to ProcessWire to be processed and saved, and a customer app where the customers can view their transactions, update their profile, and claim rewards. It also serves as a marketing tool as it sends promos and news articles to the customer app. We've finished our client training last week and we're set to be fully deployed by the end of April. I guess what I'm trying to say is, ProcessWire is awesome!

Perfmon Debug Toolbar is a Processwire module used in performance monitoring and optimization. This module has been kicking around for some time, but I finally got around to publishing it. The user interface is heavilly influenced by django-debug-toolbar if anyone is familiar with that project. During install, $config->debug must be set to true for the toolbar to run, the module is not intended to be enabled on production. The primary goal of the module is to identify bottlenecks and help tune up code. More information is here: https://github.com/KeeneState/DebugPerfmon Please let me know if you have any difficulty installing or running it. It's intended to be run on a development instance, though it can exist in a dormant state in production. Collapsed presentation (top right of screen): Expanded Presentation:

Than you, it works Certainly I will dive in into php and Processwire. Thank you all for help

This week we've got major upgrades to ProcessWire's selector engine, a great new version of Form Builder, and a few other core updates as well! https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/

: Guys, this is sooooo cool !!! Having seen the modifications done to the bike, and checked with google, this is not fake, but for real !! Discharge from coding for 4 minutes and enjoy watching this => It actually starts at 1:12 .

Find attached the first Alpha Version of the Module ProcessSetupPageName with Multilanguage Support. I tested it under various circumstances and it is doing fine with one exception: Until now it doesn't work together with 'Page Name Extended' (since PW 3.0.12) which allows UTF8 Page Names. Module requires PHP >= 5.4.x Download from here: EDIT: Removed link, download last version from here: https://github.com/kixe/ProcessSetupPageName/archive/master.zip Would be nice if you could test it and give a feedback to me. Thanks in advance.

So a while ago I started a thread about using an existing processwire as the back end for a mobile app. There was some discussion about how viable it was, but i've been working with another developer and we've started to get somewhere. This iOS app https://appsto.re/gb/mtaH_.i uses http://www.dudmc.com/ as the back end. It's not perfect but we're pretty pleased so far.

I believe that FormBuilder is not compatible with every Fieldtype and that may be the cause of your problem.

Thanks for that code snippet Kongondo. It was throwing a fatal error for me, but I added $p->setOutputFormatting(false); and it worked a dream. Here's my (fractionally) modified code: foreach ($pages->find('template=template-with-views-count-field') as $p) { $p->setOutputFormatting(false); $p->views_count = (int) $p->views_count_old; $p->save('views_count'); } Just thought I'd post feedback in case anyone else wants to use it and encounters the same fatal error

Oh, of course. When using this kind of foreach structure you have to reopen PHP to echo your object properties. You can open it with <?php or echo them with the shorter version <?= <?php foreach ( $pages->find('template=single, limit=5') as $single ):?> <div class='post'> <div class='content'> <a href='<?=$single->url?>'><h3><?=$single->title?></h3> </a> </div> </div> <? endforeach; ?> You can also use the most common PHP structure, where you don't go in and out of php. Your choice. Anyway, I think you would benefit a lot from studying the basics of PHP while using ProcessWire.It's not hard at all and will making everything more clear for you.

A minor correction to the above example: change the ";" at the end to ":"

Is the template name of your single blog posts really "home-single"? If not, you also have to change "home-single" in your pages->find selector to the real name of its template (in @diogos code example). Ah, - and welcome to the forums @Mijo.

To extend the above example to hide the name, template and parent fields on the settings page of invoices, you can add the following to the ready.php snippet in the above post. /** * Work out if the template's settings should be tweaked to hide things that should be fixed... */ function shouldHideTemplateSettings() { // Super users retain super-setting-edit powers if (wire('user')->isSuperUser()) { return false; } // Are we even editing a page? if (wire('page')->process != 'ProcessPageEdit') { return false; } $id = (int) wire('input')->get('id'); if (!$id) { return false; } $editedPage = wire('pages')->get($id); if ($editedPage->template->flags & Template::flagSystem) { return false; } if (!isInvoiceTemplate($editedPage->template->name)) { return false; } return true; } /** * Hide some fields from the invoice settings page from non-super-users. * * There's not much point allowing edits to the name field, so we want it immutable (at least) and probably totally * hidden (better.) * * We don't want invoices being moved from their parent, so we hide the parent field. * We don't allow them to use a different template, so we hide the template field. * */ if (shouldHideTemplateSettings()) { $pages->addHookAfter("ProcessPageEdit::buildFormSettings", function($event) { $wrapper = $event->return; // To show the name field but make it immutable $wrapper->_pw_page_name->collapsed = Inputfield::collapsedNoLocked; $wrapper->_pw_page_name->description = ''; // Alternatively, to hide the name field do uncomment the following and comment out the 2 lines above //$wrapper->_pw_page_name->collapsed = Inputfield::collapsedHidden; // Hide the template changer, invoices can only use the invoice template $wrapper->template->collapsed = Inputfield::collapsedHidden; // Hide the parent page, as it is fixed in our page structure $wrapper->parent_id->collapsed = Inputfield::collapsedHidden; }); }

You would have to do it either manually or using the API. If it's only a few pages to deal with you could do it manually. Otherwise, use the API. Something like this. First, rename your current text field 'views_count' to something like 'views_count_old' Create an integer field called 'views_count'. Add it to your template (the one with pages requiring view counts) Backup your db Run the code below in a template file (doesn't matter which one) on a test install first if you can. If all goes well, run on your 'real' install If all went well, remove 'views_count_old' from the above template @note: Written in browser and haven't tested but it should work. If you have thousands of pages you will want to do it in batches foreach ($pages->find('template=template-with-views-count-field') as $p) { $p->of(false); $p->views_count = (int) $p->views_count_old; $p->save('views_count'); }