Leaderboard

Makes sense, thanks. While I think PW core needs to remain kind of independent of a specific theming system, I do agree more options here would be helpful if we had some ways for the audiences you mentioned to be able to get up and running without delving into development. It's not just a matter of those audiences, but also could be helpful to us on projects where we don't really have much of a budget to work with, but just need to get something up and running without having to resort to WP, SquareSpace, etc. So I definitely support the idea of community profiles like this. But of course the foundation of PW's core is that it doesn't produce front-end markup. Site profiles are independent of the core, so it works well that way. The core shouldn't adopt a particular front-end theme strategy, but if one evolves on its own through the community I think it'd be beneficial for sure. What I was alluding to in the blog post is that in the short term, PW would benefit from having a few more site profile installation options from the get-go. The current "beginner", "intermediate" and "languages" profiles are focused more on developer skill level rather than "what kind of site do I want". And the "classic" profile is so old it needs to be dropped. I think we'd be better off with options like these: basic beginner site(s) for learning (like the current profiles) business/corporate site multi-language site (business/corporate?) blog site brochure site (single page on the front-end?) Maybe some other options would be worthwhile too, these are just the first that come to mind. But the point would be to have more starting points that are closer to what someone's looking for in terms of their actual needs. Rather than being bare bones like the current site profiles, these would be attractive sites in their own right (hopefully as a result of the great designers we've got in this community). Maybe a community profile would even evolve as a part of this process. I've always done it with just one page and template file as the controller utilizing $input->urlSegmentStr (or individually) for specifying actions and query strings for specific key/value things. This keeps it simple. Of course it may pull in lots of other pages, but as for the service itself it usually needs nothing but a single page and template. Usually when people are building a web service, they are trying to accommodate some specific need. So a lot of these details become irrelevant when building something to answer to the need. If building a full blown REST API, then yes it gets complicated because you have to account for anything that anyone wants to do. But this doesn't change the reality that building a web service for a specific purpose in PW is incredibly simple, and probably more often simpler than even configuring a full flown REST API, if it existed. Showing the right content type when an error occurs is a given, so yes one shouldn't leave uncaught exceptions, of course. I might not have understood what you meant on that. Using PW's $input var does not override using PHP's $_GET or $_POST vars. Honestly I use whatever is more convenient in a specific instance. Most of the time I prefer $input, but if need something outside the scope of $input then of course I go to PHP's superglobals. There isn't really a major benefit to using $input unless you are chaining it with a sanitizer method at the same time. Years ago, portable coding around these superglobals was annoying because you had to determine if PHP was messing with the data, like adding slashes to input. You don't really come across this anymore. PW's $input is not meant to replace the superglobals, it's meant to provide an alternative to them that may be more convenient in many cases. This is again a reason why I like the simplicity of building services to fit the need. I fully support a REST API in PW, but am just not convinced it would save anyone time except maybe non-developers. Like you mentioned above, PW has quite a diversity of possible data types, and always will (since Fieldtypes are modules, and anything can be installed). So a REST API that accommodates anything could become quite complicated. All the while, web services for specific needs remain one of the simplest things to build in PW. The biggest benefit of a full REST API in PW as I see it would be for marketing, for having a box to check, etc. And I can't argue with that.

@since 1.1.5 added CTA Button to ProcessDatabaseBackups page (edit backups) 2016/11/28 for anyone wondering as well

i guess a blog-post with a good tutorial about how to create the most simple rest api and then, in the next steps, adding things like error handling and authentication and so on could help a lot for bringing in light to this topic there's already the great tutorial of @gebeer , but i guess that's not what looks "incredibly simple" to the eyes of someone who does not have a dev background...

Yep, just realized myself that it's not documented. Now it is.

This line is different to what you show in the codeblock above it: namely, there is the extra ->id in there. The ID property of a page is an integer, so it doesn't have a mainImage that you can call size() on. If you remove the ->id it should work, but I recommend you check to make sure mainImage is actually populated (i.e. that an image has been uploaded to the field) before you do size().

Looking at this, it's got a lot of what I needed! I added a few other little features, but thank you for this code! It's been very helpful! @adrian I never would've found this on my own - thank you!! I never would've been able to see how Process modules worked without this file, either: https://github.com/ryancramerdesign/ProcessHello/blob/master/ProcessHello.module.php Lastly, here's the repo for the module I made - I'd love any feedback (There are definitely some janky bits)! https://github.com/ethanbeyer/ProcessWire-Blacklisted-Page-Names-Module

Could it be that the page has set a status that prevents deletion like Page::statusSystem? In that case, removing the status flag before deletion should make it work. This can be seen in the "Settings" tab.

As alternative to this part of code you can use "Default value (when empty)" in image field settings.

What adrian wrote + simply "/site/templates/admin.css" works too (it's loaded by AOS if exists).

@tpr is referring this option in the AOS config settings which lets you load additional CSS rules to the PW admin.

Hey, The Form API has CSRF protection build in, but if you for some reason don't want to use the API you can however use the CSRF protection. Its very simple but it took some time for me to find out, so i figured i share my findings with the rest. What is CSRF? First you need to create a token and a token name you do that as following: $tokenName = $this->session->CSRF->getTokenName(); $tokenValue = $this->session->CSRF->getTokenValue(); Very simple. Now what you want to do is create a hidden input field like this: $html .= '<input type="hidden" id="_post_token" name="' . $tokenName . '" value="' . $tokenValue . '"/>'; Now this will generate something that will look like this: You are done on the form side. You can now go to the part where you are receiving the post. Then use: $session->CSRF->validate(); This will return true (1) on a valid request and an exception on a bad request. You can test this out to open up your Firebug/Chrome debug console and change the value of the textbox to something else. Basicly what this does is set a session variable with a name (getTokenName) and gives it a hashed value. If a request has a token in it it has to have the same value or it is not send from the correct form. Well I hope I helped someone.

It's intentional, I wanted it to be smaller. In the Reno theme it looks OK but I agree that it's not that beautiful in the default. I'll remove the styles for the default theme in the next version.

@thlinna I do not know if it will be of any help, but I myself do not migrate any db at all. Instead I build my workflow around this: http://tltech.com/info/mysql-via-ssh/ I put together a bash script to completely automate the process, and normally I can clone the live db to my local machine in seconds (small databases...). This way I always have to work on the live site to make all the necessary changes, afterwards I have to clone the db, but it is an easy to follow workflow and dead simple It might be too simple for teams, but a solo developer cannot go wrong with it, at least I'm quite happy with it, I got used to working this way. Sure, I have never had to work with really big databases, but these days even transferring dozens of megabytes does not take long.

Thank you @adrian for the prompt reply. It worked Much appreciated!!!

Likely a PHP version difference. Try replacing: $this->page with: wire('page')

@thlinna I have been working on a module, a more non-dev-friendly approach the migrations module for about one year (on/off). I am actually using it all the time but it's not ready for public. It has many bugs I know how to circumvent and next to no documentation. It's similar to JSON Installer module, but more powerful and the data files are written in YAML. Perhaps JSON Installer can be of help to you.

That depends on the exact definition of "most popular". If its just the number of visitors for each post, you could add a visit_counter field to the blog_post template and include the code shown in this post in blog_post.php which increments the counter with each new view per session: Then you could simply run a selector with "template=blog-post, sort=-visitor_counter, limit=x" to show the top x most visited posts. To get it visible: use one of the templates like blog-recent-posts copy it and its PHP file to blog-popular-posts adapt the selector in the PHP file like above create and publish a page "Popular Posts" for the new template and finally add "blog-popular-posts" to the $template array in blog-main.inc (line 16) so it shows up in the navigation (untested!)

v106 is up some fixes to the issues mentioned above. I couldn't duplicate adrian's issue not showing the action labels on hover so it's probably not fixed

@bernhard CronjobDatabaseBackup and ProcessDatabaseBackups are siblings. I put them a little closer together.

Pushed update 1.1.5

Thanks @kongondo it works know

Hi all. Very minor update (I didn't even change the module version - it stays at 007). I think I've fixed the bug where long images would stay fixed at the top on scroll up in list-view. @Nukro, if you don't mind, please download the latest zip file(still MediaManager-007.zip), test and let me know if this fixes the issue? The only file that needs replacing is ProcessMediaManager.js. Thanks.

Ok, the penny has dropped finally :-p I needed a default image so I could visualize how the page looked... <?php $publish_date = date('d/m/y', $entry->created); $created_by = $entry->createdUser->displayName; if ($entry->mainImage) { $image = $entry->mainImage->size(768, 280, 'center'); $thumbnail = $image->url; } else { $thumbnail = $assets . '/images/placeholder.jpg'; // <<< my page is full of these! } ?> I think that check for an image may be a good idea. Thanks people.

Thanks, that's already corrected here. Actually I removed that part entirely - I added page-template and page-id classes to the body but there were already classes for that (ProcessPageEdit-id-1033 etc).

When editing field settings (Setup > Fields > my_field) I'm seeing an error: PHP Notice: Trying to get property of non-object in ...\modules\AdminOnSteroids\AdminOnSteroids.module:1224 BTW, thanks for making this configurable:

0.8.6 : Optional set a prepend text Find out which Twitter-account is connected when saving module 0.8.7 : Supports FieldtypeCroppableImage3

I'm guessing: The 2013 sub-list is showing up twice, because there are 2 members having this date_begin - and if you had 3 of them, it would show up three times...? $years = $page->find("template=member, categ_team=$categ"); I think this PageArray will contain each year several times - one for each member having the same date_begin. You could try $years = $page->find("template=member, categ_team=$categ")->unique();

Dynamic Selects version 003 (released (27/11/2016)) Happy to announce that the latest release of Dynamic Selects is now available for Download/Purchase. IMPORTANT If you will be using this module in the frontend please FIRST READ at least the following topics in the documentation in their entirety. Security Settings Introduction to frontend use Example frontend use Debugging results in the frontend I have spent a considerable amount of time developing and testing security features to make using MarkupDynamicSelects safe. If you believe you've come across a potential vulnerability, I would appreciate it if you could send me a PM/email about it, thanks. @note: Currently, the Excluded Templates + Included Pages combo does not work as expected if you use more than one range of IDs for either. In such cases, please stick to comma-separated values. Changelog Frontend Dynamic Selects: Added Process- and MarkupDynamicSelects. Expanded included/excluded settings to cover templates and pages.

Oh *facepalm*, I completely forgot about this! Thanks Adrian for reminding me. Its now working... Thank you TPR.

What you are describing is already what PW is for the most part. Though maybe there's additional helpers that could be added to support the front-end developer as you mentioned, I'm not sure. But what simpler context for a REST API could you have than what PW already provides? My experience has been that this kind of module is counterproductive – I deleted the web services module I'd built awhile back because I thought it costed people time rather than saving it. Maybe what's needed is a guide showing you how to implement a simple REST API on your own, without any module, since PW already makes it easy. But I appreciate your comments and will certainly look further into both options. That's basically a theme – what WordPress, Drupal, etc. are for. I'm not against the idea as something for us to collaborate on as a community, but from the core standpoint, it's the opposite of what the core aims to provide. Great ideas regarding the "community" profile, and I think it makes a great community thing, just not a core thing. I don't want to blur the line between PW and platforms like WP, Drupal, etc. Though I do think it's good to show that PW can do these things too. But if we had community efforts like this (and more diversity of profiles separate from it) the core really wouldn't need anything other than a blank profile. Though until that time, I do still think it's good for the core to demonstrate the diversity of output possibilities at the simplest level. These are still on the roadmap and have been for awhile. What gets implemented depends on resources, but front-end image resizing seems like it's got good potential for the near future, while front-end $pages API may take longer (but I still hope to accomplish that for 2017). Chances are I won't be the one developing the front-end image resizing stuff, as the ideas were brought in by another person, and I know little about it. But it is also one of the features that gets me very excited, so hopefully we can get some momentum going on this soon.

the sad thing is i do not expect to get an answer here as i put some time im my last post and did not get an answer either... anyway, from the roadmap 2016: what about the client side image resizing? that would be REALLY helpful in many of my projects... i'm still voting for a rock-solid image handling field. like cropping in predefined ratios and so on. that's an often discussed topic and i don't think that horst's awesome cropping module is the best solution... in my opinion it still feels like a workaround and not like processwire awesomeness... but of course many many thanks for all the great work that lets me have so much fun in my everyday work

@ryan I have a suggestion regarding the Roadmap. Why not providing a REST API as a pro module or in the core? Headless CMS are on the rise and there's a huge market of Front End developers (Angular, React, VueJS) that would love this. Caching and JWT auth integration would also be appreciated. At the moment setting up a REST API requires a little bit of set up, which may be trivial for a PHP developer but a little difficult for a Front End developer. For example looping all fields, by default won't show image fields or repeater fields, you have to add specific code to get them properly.

Here is a server-side alternative to (or backup for) the JS validation. $this->addHookBefore('ProcessPageAdd::processInput', function($event) { $form = $event->arguments('form'); $input = $this->input; $sanitizer = $this->sanitizer; $template = $sanitizer->int($input->post->template); if($template !== 43) return; // the ID of the template you want to limit page names for $name = $sanitizer->pageName($input->post->_pw_page_name); $parent_id = $sanitizer->int($input->post->parent_id); $uri = $_SERVER['REQUEST_URI']; $blacklist = ['cat', 'dog', 'hamster']; // your blacklist if(in_array($name, $blacklist) ) { $name_field = $form->children->get('_pw_page_name'); $error = "The page name '$name' is reserved. Please choose a different name."; $name_field->error($error); $this->session->redirect("{$uri}?parent_id=$parent_id"); } }); A little awkward but does the job. You could incorporate into a module to get a configurable template selection and name blacklist.

This is the first time that I'm going to post anything under the showcase forum, although I have a few ProcessWire powered websites under my belt. This one is special because I think the use case is somewhat unique. Caltex Loyalty Club - initial the situation Caltex Loyalty Club is a customer loyalty and rewards program of Caltex Palawan aimed to provide exciting promos and incentives their customers' continuous patronage. Caltex Palawan originally bought their system from a large software company that also provides card-based solutions. The previous system consist of the following: two high-end Dell servers that are located in two separate Caltex' offices traditional EFTPOS devices for reading loyalty cards MIfare RFID cards as loyalty cards Running within one of the Dell servers was a crude and barely usable loyalty/rewards manager application that runs the whole thing. Here's what I mean: You're free to imagine what the rest of the application looks like. The other dell server acts as a VPN server through which all the EFTPOS devices and the application server connect to. To cut the long story short, this setup was running smoothly for a total of 3 weeks before problems started popping up, mostly because VPN server did not have a static IP address and the EFTPOS devices could not connect. The developers refused to provide service to the system because Caltex Palawan does not want to shoulder the travel and boarding expenses of the developers (since it was just working 3 weeks). We were called in at this point (we being a local tech solutions provider in Puerto Princesa), and we made the VPN server work, but other problems soon surfaced. The whole system was barely working for about 3 years when they finally decided they were fed up with the customer complaints they keep getting everyday. Our Solution We studied the existing system for quite some time to examine where the problems we're coming from. The most obvious one we found was that because the servers were located inside Caltex Palawan's offices, the servers were prone to downtimes caused by power outages and internet connectivity problems. It was obvious that the better way would be a web-based solution that would always be online. We also wanted to replace the bulky and outdated EFTPOS devices with android based NFC device that are more portable, and easier to work with. We retained the cards that originally came with the system since there are thousands left unused, but eventually replaced them with NTAG stickers, and newer cards. To sum it up: A web-based application to manage the loyalty / rewards system Android based NFC device to read the loyalty cards NTAG stickers to act as loyalty cards ProcessWire to the Rescue Having used ProcessWire before, it was our best choice, after considering using Laravel, and other frameworks, because of ProcessWire's key strengths: all custom fields - no unnecessary bloat powerful api scalability Although this straight up looks like it's been lifted from processwire.com's front page, but this really is the case, and these are all we need from a web-application framework to do almost anything! All custom fields Since we are working with a unique dataset, it's impossible for us to find anything out there that would have anything even remotely close to what we need. In the beginning we were planning to use custom database tables that we would deploy alongside ProcessWire. I even posted one time in the forum, asking if there's any way to integrate an ORM library with ProcessWire, and the answer I got was that it would be redundant, and almost surely unnecessary. And this turned out exactly the case! When we designed our database (using ERDs), we we're delighted at how closely we were able to replicate our relational design using templates, fields, and pages. This is mainly due to FieldtypePage. We were able to create meaningful relationships within our templates. We ended up with ~60 templates and ~70 fields. Powerful API About 70% of our code are API calls. The rest are just control structures and simple computations. That's how powerful the ProcessWire API is. So powerful that we did not even need to write a single sql query to complete the whole project. We needed to handle user login, API has it. Session handling, API has it. Selecting and manipulating huge amount of interrelated data, the API has it! Scalability At the onset of the project, the existing CLC program already has some 20 thousand members with hundreds of thousands of transactions. Right now, our current system has around 500,000 pages and counting and were not experiencing any slowdown. How we used ProcessWire The first thing that we decided that our client would not be able to see the processwire admin page. We wanted to present them with a simplified UI that does not present them with anything they don't need. We created a whole frontend UI for the client to use. We had custom forms for all the pages that they can create, and all the actions that they can do. We, on the otherhand, use the admin backend thoroughly in continuously developing, and supporting the system. What the clients see vs what we see: Our setup ProcessWire 2.8 running on a LEMP stack DigitalOcean droplet AjentiV VPS manager Modules we used We used a very minimal amount of modules for the project: ImportPagesCSV - to import the data migrated from the old system FieldtypeDecimal - for all our decimal values Modified RestHelper - from clsource for all the communication between ProcessWire and our android POS app Modified PagesSum from esrch ProcessSelectorTest - for quickly checking some selections Things we had to do on our own Frontend user login Frontend password recovery Fine-grained permission handling for users Cron jobs for scheduled tasks. The rest are API calls, and business logic. The Result Our Caltex Loyalty Club web application is now running on its sixth month without so much as a hiccup! Compared to the previous system that was averaging 200 transactions per day, we are now getting 800 and it's growing. We are running 10 campaigns and promos simultaneously across 18 Caltex Stations all over Palawan, with 30 android NFC terminals communicating to a single ProcessWire installation. We are very happy with ProcessWire in terms of performance, ease of use, and most importantly it's simple and yet very powerful functionality as a web-application framework even though it doesn't primarily market itself as one. PS. Also one of the best things we experienced while doing this project is the awesome, unparalleled community support. Throughout the project, although we had a lot of moments when we just couldn't figure out what to do, never once did we have to ask a question in the forum. A quick search here and there, and someone already helped someone else that faced the same problem we were having. It's almost as if people are being paid to diligently answer all the questions! We most of the time just had to like an answer that was already there! Screenshots and photos Android POS terminals and CSR training

An article from April describing a strategy for deploying PW using Robo task manager http://antonioandra.de/articles/deploying-processwire-with-robo/

I'm new to processwire, but have some decent experience in Scala, python and others. I was the typical guy making fun of php. Processwire changed that, the api design is very elegant and convinced me. I can host the event in Berlin, so we have big monitors for everyone, projectors, etc. Ping me if you are interested. We can make it a mini conference, with speakers etc.

Hi @kixe, first just want to say thanks for this useful module (if I don't have already)! And I want to share a usage that propably wasn't intended with your module, but I find it useful for small sites where content changes slightly in a weekly manner or less. I use a hook into Session::logout in the ready.php file that invokes a DB-Backup. Currently the simplyfied code looks like: /* Autobackups */ $wire->addHookBefore("Session::logout", function(HookEvent $event) { if(!wire('user')->hasPermission('db-backup')) return; if(wire('modules')->isInstalled('CronjobDatabaseBackup')) { // execute a cronBackup ignore_user_abort(true); set_time_limit(120); $cdb = wire('modules')->get('CronjobDatabaseBackup'); $e = new HookEvent(); $cdb->cronBackup($e); } return; }); This is a bit hacky. What do you think about to embedd a public method to do this more transparent. Also it would be good if the description ($fileinfo) could be set dynamically with this method or as separate method or option. Currently I have hacked this into the module to be able to set it like: "logout horst (CronjobDatabaseBackup)". Anyway, also without that, it is a big, big helper!

Ferdi, thank you!! Always good to see new module authors writing for PW.

Thanks Ferdi !