alxndre

My suggestion as always would be to install Tracy Debugger, to see what's going on. The built-in terminal for example would be very useful for this. I would probably do a dump or print_r of the the $resource->image variable just to make sure if it's an array or whatever it really is.

On an unrelated note, why don't we have more videos like this? This is the kind of thing that really grabs people's attention. I think the intro video for Vue.js was short and simple but effective enough to get people (at least me) excited. Is it beyond us as a community to work on something like this?

Check your log for errors or timeouts. Do you have Tracy installed? At this point it would be your best bet to see whats going on. I've experienced this before with PageReference fields trying to load thousands of pages into a combobox options (instead of using ajax load). That's the only thing that comes to mind without any more details.

You should note that while the template editor is mainly for the developer, the page editor where you actually put content is mostly for the users (writers, ads/seo managers,business owners, etc). So the value is that you could have a functional and customized content editor with just a few clicks. It is also important to note that ProcessWire is a content manager. For me, and for most cases i think, this is much more "valuable" than a WYSIWYG front-end because while front-end design trends/frameworks come and go, the back-end would remain the same. It would be much more wasteful to support all of these trends/frameworks with drag-and-drop support only for them to be unpopular in a few months. And it's also been argued countless times that a well-crafted website design is many, many times better than a "customizable" but inescapably bloated front-end. I still cringe remembering the markup regurgitated by Dreamweaver and the likes. Not to say that the concept is without merit, but it does not fit all use cases, and goes directly against ProcessWire's unopinionated nature. Would you mind giving other examples? I've been using ProcessWire for some years on a daily basis, and I haven't once thought, "hmmm, this doesn't do anything, we should just remove it". That being said, each project is still unique, and if you think the way ProcessWire works is inadequate, that's where modules come in. Or other CMSs, for that matter. For me the strongest reason for choosing ProcessWire is simple: with what it does it does so well, and with what it doesn't it doesn't stand in the way.

Hi, first of all, welcome to the PW forums, and may I say what you are doing is exactly what I envision myself doing in retirement, still coding but for fun and learning. ProcessWire is not a WYSIWYG editor where you just move the items around and the change is reflected on the frontend. Moving around the fields in the template editor only changes their position when you are editing them in the page editor (i.e. Home > Edit). Now to change the output, you do have to change how it is "hard coded" in the template files, as that mostly is how websites are written. There are "WYSIWYG" CMSs out there like Concrete5, where you can drag and drop the "sections" of a website, but I assure you, you're better off with PW as I was working with Concrete5 back in 2012 before finding ProcessWire and never looked back. I hope this helped a bit, and that you enjoy working experimenting more with ProcessWire. Cheers.

Not sure as well, but maybe has something to do with '/' being the only saved page with a NullPage as a parent? echo print_r($pages->get('/')); // result // ProcessWire\NullPage Object ( ... ) And in the database, home's parent_id is 0, and it does not have an entry in pages_parents. Upon further digging, I also found that home is the only result when querying for "has_parent!=1", and it is hard-coded. Anyway, if you require home to not be in the result, maybe just exclude it from the query? $childrenOfHome = $pages->find("has_parent=1, id!=1");

Autojoined (autoload) fields are loaded into memory every time a page is called, in contrast with non autojoined fields which are fetched only when they are used. // if title is autojoined (by default) $something = $pages->get(123); // get a page from db echo $something->title; // no extra db hit because it was already fetched when the page was loaded echo $something->else; // pw will query the db to get the field

Wow. I really like how it gets everything out of the way to showcase the pictures.

We still used ProcessWire in areas where it makes sense like users management, presentation related stuff, routing, web API, etc. We moved all business objects to a separate database (MariaDB, InnoDB engine) and used LessQL to simplify data access. We specifically picked LessQL because working with it still somehow feels like working with the PW API. $people = $lessQL->person()->select("id, firstname, lastname")->where("firstname LIKE ?", "%alex%")->orderBy("firstname")->limit(10); About this: $page->parent->child->children()->child Well this is an exaggeration, but we really did have something similar. We worked with a C# ORM before this where it was perfectly okay to do: // pseudocode totalForThisOrderId = person.orders(id).items().sum(price) And as I've said, this was not a problem with ProcessWire itself but with the way we designed our data structure in the PageTree where we had: Transactions \_ Transaction #1 \_ Line Item #1 \_ Line Item #2 \_ Transaction #n \_ etc... So now to get the sum of the line items from the transaction where a line item comes from we'd write: $sumTransactions = $lineItem->parent->children()->sum('price'); It's far from ideal, but it was the quickest way at the time to code based on our previous practice. We're currently at around 50 million records, I think. But like I said, ProcessWire gracefully scales with this. It only starts slowing down when you try to aggregate or count something huge. We were doing reports on hundred thousand records at a time. It still worked, but it was far from fast -- which was mostly our fault. Using LessQL with ProcessWire allowed us to transition without starting over from scratch, and still have the all the benefits of ProcessWire which made us decide to use it in the first place.

@theo I've experienced transferring data both to and from ProcessWire with no major issues, and this was before the new import/export features which I haven't tried yet. Exporting data from ProcessWire is straightforward using CSV, or SQL dump. One thing to watch out for (but might not be a problem anymore with the new import/export features) when transferring to ProcessWire is making sure the order of templates are correct, meaning you have to import templates that are needed by other templates through PageReference. But it's all in all relatively painless.

Hi. Welcome to the ProcessWire forums. Have you already read on the concept of page/templates/fields? If not, this is a must read article to fully understand how ProcessWire works: ProcessWire CMS – A Beginner’s Guide ---- Now to your question: This i not true. You only need to assign these fields into one template, and then create a page using that template. For instance, if you assign these fields to the home page, you'll be able to access them everywhere. Once you edit the home page assign values to these fields: Home -------- footer1 [ left foot ] footer2 [ right foot ] footer3 [ middle foot? ] In your foot.php you could have something like: echo $pages->get('/')->footer1 . PHP_EOL; echo $pages->get('/')->footer2 . PHP_EOL; // or $home = $pages->get('/'); echo $home->footer1 . PHP_EOL; echo $home->footer3 . PHP_EOL; // output: // left foot // right foot // left foot // middle foot? I suggest you make an effort to fully grasp the page/templates/field concept, because after that everything in ProcessWire come really easy.

It depends on how big is big. In one of our bigger projects, we designed the whole system around ProcessWire's page-templates-fields paradigm. It was designed in such a ways that it looked almost like a normalized relational database with PageReference providing the "relationships", but with each page easily editable in the admin. This was working well, until it wasn't. I'm guessing it was because we "normalized" the data too much that we were hit with performance issues when we started making big queries specially with aggregates, and with traversals. Of course this wasn't ProcessWire's fault but our own because we wanted so much to be able to code using mostly PWs API and very minimal raw SQL. Our intermediate fix was to write the queries manually to make the huge queries. But after a while the solution felt dirty, so in the end we refactored our data, pulled them out of ProcessWire's database and moved them to a separate database. We used a half-and-half ORM solution to access the data and wrote custom modules to edit them on the backend as @Macrura suggested. So what I'm trying to say TL;DR is: If you want to use PW to manage your database, it'll be great. It's not how "big" your data is, but how complex the relationships will be. And maybe not even that. It depends on how much you want to rely on the API to get your data. We were doing all well and good until we wanted to get something like $page->parent->child->children()->child on some reports, or something similar which of course resulted in hundreds of JOINS. (Don't do that, seriously, we were stupid. Lazy and stupid ). But if it's something where you're doing huge queries and reports, it will work but it will not be the fastest unless you start writing custom SQL queries. If you're lazy like me, use an ORM if you decide to use a separate database. But this of course will have an overhead in learning curve and in writing the custom modules for the admin. I hope this helps. :/

Done. Star #303. Also from now on, I pledge to star whatever module I download.

Unrelated, but I've been struggling with gif screen capture the whole morning, and your post saved my day. Thanks.

Easiest, fastest, most reliable framework. Considering my workload this past weeks, I'm considering on switching. It supports a wide range of applications:

This is what I do. I find it easier to view the source (inspector) and rebuild from there, rather than work with the raw files from WP.

I'm doing something similar (far from being as awesome as your module) using only some hobbled up pages and templates, and it's getting out of hand. This looks worthwhile to dig around in. I'll try it out and try to give helpful feedback. Thanks for sharing.

There was a recent post somewhere in the forum of a video of Rasmus briefly explaining (sort-of) why PHP was "bad" at the beginning, and how far PHP has come in 2017 with PHP 7+. I personally love PHP despite its reputation because it's almost as old as the internet itself, and has endured with it. While that's not directly a measure of being a good programming language, it's a measure of stability that means anything I learn doing in PHP will be useful for years to come, unlike how some modern frameworks/language/libraries come and go. And like horst said, there are always good and bad coders regardless of the language. Just like how they hail Python as a good programming language, but I've seen some people write some horrible stuff in it, ProcessWire is probably one of the best things I've come across that's written in a "bad" programming language.

Thanks for this great module, @Robin S! Can i request to add this as I still think this is useful, and it fits within your module:

Hello, out of the topic, but what module is this? Thanks.

Are you using the latest master? If you haven't already, try adding a ProcessWire namespace to your file, or use function ProcessWire\wire : <?php namespace ProcessWire; use function ProcessWire\wire;

This is a simple loader for LessQL, an ORM alternative for PHP. It is based on NotORM, and provides a quick way to access and find things in a database, including traversals and back-traversals. As discussed in some earlier topics, there are times when you'd like to store some data away from ProcessWire's pages/fields/templates structure for whatever reasons. However ORMs are sometimes cumbersome and requires a lot more effort to deploy. LessQL offers a quick way to just up and go like you're using an ORM but without the added complexity and configuration files. Module: https://github.com/alguintu/LessQL This modules simply loads the LessQL library into ProcessWire and exposes a $lessQL variable (configurable in settings) that gives access to your database. It uses the same database specified in $config by default, but can be set to use a separate database, along with its credentials. Usage given a table person : $people = $lessQL->person()->select("id, firstname, lastname")->where("firstname LIKE ?", "%alex%")->orderBy("firstname")->limit(10); It uses lazy loading and doesn't execute the query until it needs to. Checkout www.lessql.net for more info on LessQL. Module wrapper is pretty much lifted from @teppo's RedBeanPHP module, but with a few modifications.

I'm an idiot. So it's because I'm watching the log page trying to poll the logs. Thanks guys.

Hi @abdus, the modules I tested are both set to 'singular' => true.