LostKobrakai

You even have the option to store this relationship explicitly by using separate pages with pagefields for both user and private page But in the end: Try to look for what's most natural in the workflow. Your clients will most likely create the user before the private page, which would conclude that the page field should rather be stored on the private page as the user is already created by then.

Just some additions to teppo's point 1 / 4 (mvc and routing): In my current big project I'm using a hybrid strategy, where simple sites just use the default "file per template" – even though we have a dump router in the beginning to allow for different folders based on the rootParent – and for more complex pages / page-structures I'm using FastRoute in those template-file to route different urlSegments to a controller class. This way I don't need to roll a controller class for each and every tiny page, but still have the option to fall back to such a class if the need for more structure is there.

The thing I'm currently missing the most is probably a clear path to testing, which is still not the easy thing even in other libraries. Also you need to consider, that you'd need to implement any application logic (and it's structure) on your own, where other frameworks might already give you a predefined path e.g. for handling domain-events or queuing messages or just about where to put certain parts of the application. Validation is also a thing. I'm using nette/forms here, to have form generation and fronend-/backend validation covered.

Sad to hear that you're put of by this, but the demo is mostly a showcase on how content modeling is handled in processwire and a peak into the admin backend. (Frontend)-Performance is dependent on so many factory, that the demo won't give you any reasonably insight anyways. E.g. we just recently switched hosting to a new quite beefy bare metal server, which is understandably faster than the previous one. Would you consider ProcessWire better because of that speed improvement? In the end rendering speed is probably most dependent on what you're implementing with processwire as on the system itself. If you really want to evaluate processwire by the demo: ProCache is only active for guest users, therefore as soon as you log in as admin you'll not get any ProCache cached content. Also the whole backend interface is not cached as well and really it's just another kind of frontend rendered by processwire. Additionally you won't need to ask for a new demo, you can install it yourself using the skyscraper installation profile.

This can certainly be done in ProcessWire, but depending on the scale of application you're aiming for I'd also consider something like laravel. Mostly because things like support for S3 file hosting is already built-in.

Here's a nice (laravel centric) overview about what valet is and how to get it running: https://laracasts.com/lessons/laravel-valet-is-the-bomb

Especially as e.g. zepto will give you probably 99% of what you're using of jquery in a fraction of the filesize.

It's not that hard to create your overall layout with floats or inline-block styling and it just works and you'll hardly have any browsers not being able to render it. Why then use flexbox, which is really meant to style content "in-a-line (column)" and not a whole grid of content and introduce issues like mentioned above or the browser support.

I'm using Susy in a current project and I'm so annoyed of having to clear floats all over the place, let alone that neither nth-child nor nth-of-type are capable of recounting items if you're hiding (adding/removing classes) some elements in the flow, so removing the first/last margin is a pain for dynamic items. As long as I'm using fixed gutter width's I'm using a mixin version of inuit's layout object. Might not be as powerful, but at least more sane.

You're probably triggering the hook on the newly created page object. The created timestamp is (probably) not part of that object by then and won't be available until the page is loaded from the db for the first time.

Double click a trashcan.

@Bill C Depending on your knowledge in managing linux servers Docker might not be a good fit. It does make things easier for experienced people, but if you're just getting into it it's just another complex layer.

I can certainly see the intent, but I'm always cringing when I see something like that. A website is first and foremost for users and I'm not really seeing why the user should download 1.5 times the size of data, just to have lot's of (duplicate) content appended in a only machine readable format. In my mind, if it should be machine readable then supply an api to do so. It might seem verbose, but I'm more in favor of something like h-card, which is just wrapping around existing content. But in the end I'm also the one being quite glad about hardly working in the hell of SEO

I find things like laravel valet + php-version much more interesting for a simple dev environment compared to vagrant or docker. At least if you just need a PHP version and something mysql. For setups more involved with the infrastructure I'd also rather suggest trying Docker today, as it's Native-App Beta is doing great and the speed improvement and deployment options are just far superior. The only reason I'm currently still developing on a vm is that I'm working on different machines and don't want to hassle with updating the database back and forth. Put the vm on an external drive and done

If I remember that correctly some of the clients I'm working for are using specialized translation software, as lot's of the marketing speech is already translated somewhere, especially company specific terms and phrases. And I doubt that someone is supposed to translate those 7000 pages of tkaranka fully by hand.

viewable() is called as part of fieldViewable() and that one is called at least for each FieldsetTabOpen. They'll just get more and more

http://codepen.io/LostKobrakai/pen/jrOqBL?editors=1100 That's rather the issues I'm talking about. Plain classes without other selector elements are trumped by pseudo-classes, which need another selector element and therefore are inherently more specific.

My only issue with those otherwise great pseudo-classes is that they increase the selectors specificity. They just cannot be overwritten anymore by any styles added via a class. Otherwise I would also use :not() far more often.

I'd really like to see a PageTree object, which can hold a (whole or partial) page tree in memory. This would allow for testing stubs and similar or the api creation of a whole tree branch at once. But sadly the PageFinder class is often dependent on mysql functionality, which by now does not have feature parity with the in memory selector engine. Also a page tree object is not really like a multidimensional array, but rather a array of pages, which optionally hold another array of children. The concept this is more like e.g. the pw form api does work with it's fieldgroups. I could imagine something like this: class Tree extends WireArray{ public function isValidItem($item) { return $item instanceof Branch; } […] } class Branch extends Wire{ protected $page; /** @var Tree $children */ protected $children; function hasChildren(){}; function getChildren(){}; function addChild(){}; […] } Edit: Really nice could also be a base Tree class, which both a PageTree as well as e.g. the Forms API could inherit from. This would also allow for easy implementation of other (custom?) tree based constructs. Nested comments for example just came to my mind.

PageArray's (as well as it's parent class WireArray) can only hold one dimensional data on their own. You could however try using a WireArray to hold multiple PageArrays.

Did you try different sharpening settings? Also that's not really a issue with processwire's imagesizer class, as the actual resizing is always done by external image processing libraries like gd or since 3.0 also imagemagick.

My answer from above does probably also fit to this issue. Users are only meant to be edited via Access > Users and not anywhere else. Normally it doesn't stand out as much as the default user template is a system template and it's pages are hidden in the Admin branch of the page tree.

Iirc the user accounts are only editable via the page tree by superusers. Generally the system is built so that all user editing should happen in Access > Users and not in the PageTree.

You're not() selector is not valid. Select pages with empty fields by using this format "field=''". With or-groups you can also combine both selectors to a single one.