alxndre

I don't know if it's the best practice, but i normally just organize all the files inside the templates folder since it's easier when you import/export site profiles because they get included. My normal file structure looks like this: I place all 3rd party plugins (jquery, bootstrap plugins, etc) under the vendor folder. I also use a somewhat MVC (not strictly) approach, so I place all my controller files in functions folder, and all my views in views folder. You get the idea. I hope this helps.

wiki.processwire.com is also down. :|

Have you tried: $stats = wire('pages')->get("/stats");

What exact error/exception are you getting? I just tried this in one of my installs and it works: $price = $page->pricebulletin[0]; //unpublished pagetable page wire('log')->save('dev','price: ' . $price->id); maybe you're missing something else?

Maybe save the parent ID in the session instead and then get the page again using the id.

You could use the PageAutoComplete input for page fields so the page would not load all the people at once.

To me, Option 1 seems more logical, and more organized. Page links would be more useful and intuitive in the future when you're trying to select related data, rather than finding them through a node's children. Consider: $pages->find("template=event, personreference=$person"); against: $pages->find("template=event, has_parent=$person"); I think the first one would be easier to understand, and would execute faster.

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

Assuming you want this in the current template and you want the root domain , your code should be : <title><?php echo $page->get("seo_title|title") . " | " . $pages->get('/')->httpUrl; ?>

Thanks guys! Got it fixed.

Thanks, Peter. I just tried doing this and found the cause of the problem. The transactionreference field causes the server to timeout because it is a page field that has >5000 possible pages to be selected. I'm guessing this happens while the pageedit process is trying to populate the select input for the field. What's the best input choice/setting for something like this? Thanks again.

I confirmed that it isn't the cause. I populated the titles, and it's still the same. I will try this later tonight when the system is not in use and after a backup. Thanks.

Hi, tpr. Thanks for the reply. I checked the logs in both the ProcessWire admin (Setup>Logs) and server logs (php-fpm logs, nginx logs) and nothing seems to indicate possible causes. I noticed that these pages' titles are blank. Could that cause this error? Thanks!

Hi, I'm having a weird problem and I don't know how to fix it. We've built a large-ish system and it has been running alright for almost a month now, no problems. Then today, I had to check an area that we haven't paid much attention to. It's a collection of pages that hold the details of certain transactions. Now when I try to edit the page, it tries to load for a long time, may a minute, and then throws a 500 error. The template only has 3 fields, so I can't figure out what could possibly be causing the error. The template works when used within the templates or when searched. It's just that opening/editing them in the admin throws the error. Has anyone else encountered this? What could possibly cause a page of a certain template to not load? All the other pages open normally. Any help is, as always, greatly appreciated. Thanks.

Hi, thanks for your replies. In SQL, I usually cast the integers to string first so it can be used against LIKE. But I can't find enough examples using $db->query to do it. I'd keep searching for now. Thanks again.

Hi, I'm trying to get partial match for fields of type integer, much like how %= and *= selectors works for string. Unfortunately these selectors are not working with numeric fields. Is it possible to do this? For example, if I have pages with control numbers 14975, 91432, 33333, 32414, 13256 I'm looking for something like: $pages->find("controlnumber%=14"); that would match 14975, 91432, and 32414, that would work for numeric fields. Thanks.

I did this once because I created a whole backend area for the users, and didn't want the user to ever see the processwire admin. But i usually just leave as it is if the client is okay with it, or like @OrganizedFellow, i change it to something appropriate.

Hi, I've been trying to figure out what's wrong with this error that I encountered, and I can't find it. I used to have a field called "cardstate". I then deleted this, and removed all references to it in my template code. All was doing great, until suddenly, this error popped up. PageFinder seems to be trying to include this field when searching even though it is not referenced anywhere. The code that triggers the error is a simple call to a page's children with a set limit. foreach ($page->children("limit=10") as $trans) { ... // some looping code } If I remove this limit, the error does not occur. Is there any place that the field might still be called? Perhaps somewhere in the database, or something went wrong when I deleted it? I'm scratching my head over this. Help. Thanks. UPDATE: How do you delete a post? I was stupid. I finally found an include statement that does use the field inside the file. Sorry.

If your week starts on sunday $d = strtotime("today"); $start_week = strtotime("last sunday midnight",$d); $end_week = strtotime("next saturday",$d); $start = date("Y-m-d",$start_week); $end = date("Y-m-d",$end_week); and then filter your pages like this: $results = $pages->find("datefield>=$start_week, datefield<=$end_week"); where datefield is whatever date field you are trying to filter.

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!

Hi, I'm trying to figure out if it's possible to add a "field" of some sort to the templates. See, this "field" isn't exactly a like the regular fieldtypes that would have different values depending on the pages that use that template. What I'm looking for is almost exactly the same as the Tags field in the advanced tab of the template settings. My use case scenario is that I want to put some keywords in there that would be available to all the pages using a particular template, and then I could perhaps use those values to determine dependencies, etc. I could actually achieve this with the existing tag field, but then it messes with the templates list because they appear multiple times depending on how many tags I put in them. So my question is how or if it's possible to add another field like it to templates? Thanks.

Is there a way to get parameters from patch, put, and delete? Rest\Request::params() doesn't seem to work with these verbs?

Is there a way to get parameters from patch, put, and delete? It doesn't seem to work with these?

Is there any reason why the profile exporter would not export ALL the content of the email field? I used the default system email field on another template (member's emails). They are not getting exported at all. Is there a way to export them? Or should I not use the system email field for this purpose? What about users? Are they not supposed to be imported as well? Thanks.