LostKobrakai

It is the correct term and they are great! I'm using mine far to rarely in the standing mode. Besides being good for the back it also seems to keep me more focused on tasks to get done, as it's not comfortable enough to stand there just to read some random thing on the internet or other useless habits.

That introduction video! That's how you make people interested.

Are you somehow missing the home.php file? Or is there an alternative file set in the template's settings?

Yeah it looks nice, but I'm still confused why it's so hard for people to just let the page render statically (which shouldn't be a problem) and add all the fancy animation on top, so one could still read all the marketing speak without relying on loads of js. It's especially confusing when knowing that seven agencies where involved in the project.

Besides if you're changing the database structure, then you'd need to install / uninstall (or change the db manually, which is not as clean). btw: refresh button of the browser and/or modules > refresh.

Or there are just not many people into the topic. The only thing I can provide you with is that apps most often do not use session authentication, but rather oauth, which I suspect does have a reason.

Therefore, nope there's no UI, but it's certainly possible. Especially the people, who are in the need to setup multiple different listers are most likely able to setup these via the modules code as well.

It's funny to see you quote my request for such an tutorial and now I'm very much feeling able to answer your questions here. Currently the best resource for handling all those mentioned things is really ProcessWire itself. If you want to know how to handle a custom CI Design in the backend - take a look at AdminThemeReno - it was born out of a custom backend interface and then ported over to pw. Maybe the new custom colorschema feature of Reno does fit your needs, but otherwise just clone one of those admin themes to site/modules/ and tinker away. About custom interfaces: All the Process* modules represent (full) interface-pages in the backend, and lot of the 3rd party modules are injecting things into those pages. Just take a look at those an see how they handle things. Maybe the most interesting Process module is ProcessPageEdit, as it is maybe the most used one. For module that inject things I'd say BatchChildEditor is a quite sophisticated one. After a little playing around with those files and creating own ones, you'll see that even the backend consists of only a few concepts: the Process/Module Interfaces, the Form api, the Inputfield / Fieldtype interfaces and Wire / WireArray classes. The other core classes should only be from interest if you really need them.

There's no autocomplete functionality, as there's also no full directory of tags anywhere. Tags are stored as part of their corresponding image and therefore do not know anything about other tags.

As I tried to tell you above ProcessWire cannot know how to handle pagination pages, where the selector returns an empty set. Pagination isn't more than just limiting the returned set of pages. PW cannot guess what else you're doing on that page, or if maybe this empty set will be modified later. Blindly throwing 404 errors would make this system greatly more inflexible. You can always handle those things on your own just like you need it. To iterate on your 404 problem: 404 errors do always respond directly on the requested url, no matter where in pw. Only the status-code will change to 404.

Both customized listers and bulk actions are available to you without ListerPro. Just have a look at the core ProcessUsers and PageActions modules. ListerPro just provides the "more than easy to setup" interface for those things. But maybe the basic "set up a new Lister" functionality could really be move to the core Lister in the future, as the Pro Version seems to be getting other unique selling points.

I don't want to sound to discouraging, but I doubt you'll have a nice time trying to make complex modules like repeaters or image-fields as they exist to work in a non admin context. There are just a big bunch of dependencies involved. It may almost certainly be easier to create forms and controls on your own and use the api to save things.

What part do you consider critical about ListerPro, that the core Lister doesn't give you? I've sites running, which do work without any lister as well as ones, where Lister(Pro) wasn't flexible enough so I had to create custom modules to list things and add custom overviews and functionality. Therefore I don't see whats so critical about it.

It's partly that, but mostly that the whole presentation-layer is already decoupled. So you can already go and choose whatever system you like to create the presentation, while other CMSs are quite tightly couple (think of wp loops).

I just attended one of the free A List Apart live-events and was quite amazed. The big topics that were discussed were how to chose a cms, evaluating not only the frontend, but also the author/backend user experience and workflow needs and finally the current interest in decoupled cm-systems. The great thing was, that on all of those topics I was constantly thinking how nice it is to handle these things in PW. Some may include more work than others, but in the end it's really avoiding lots of those mentioned difficulties / roadblocks with cmss. So my conclusion is really "I love my CMS" . For the curious I've included the link to the event page, where the hangout/transscript will be posted later and the hangout link, so you can watch it as long as the event page isn't updated. Maybe someone did even watch it live as well. http://alistapart.com/event/content-management https://plus.google.com/events/clcdcbjo5puojn47aprk5plkem0?authkey=CMP6kImisby_tgE

That one failed that exact check. For me that was mostly a matter of refreshing modules once or twice an they were gone, but I'm not sure what exactly could fail for those rarely changed core modules.

This comes from the new "version change detection" addition from 2.6.10. It checks all modules if the version has changed and if so executes potential migration code.

By default lists of pages / repeaters are saved in the object like this: [ page.id => page obj, page.id => page.obj ] so there's no api way to directly get an incremental key. But there's the getValues() function, that returns an array while scraping all the keys, so the pages get automatically keyed by incremental numbering. Keep in mind that both indexes below are zero-based and therefore do not start at 1. foreach($pageresult->repeaterField->getValues() as $key => $repeater) { if ($repeater->subfield) { // Do something with $key } } // To lookup repeaters $pageresult->repeaterField->eq($n);

The title idea won't work as the Inputfields are only rendering title and id, but never the value. That's why this would be a bigger change to make this work, as all inputfields would need to change.

@Macrura But solely relying on the 404 error does account for pages, that may have been added after the initial page load, while setting the max pages limit previously isn't that flexible.

I'm not sure where you came to this syntax, but the $pages->get() function doesn't work with multiple parameters. Also a single page can hardly be sorted in any way. $stellen = $pages->get("id=1035, include=hidden")->children; $stellen = $pages->get("id=1035, include=hidden")->children("sort=sort");

If you're using the masonry package you should also take a look at the stamp option, which doesn't depend on the item order. At best your message should be the first item, if something on the javascript side fails, that it's still at the top and not buried beneath lots of thumbnails.

ProcessWire must leave it up to you to handle those 404 errors, as it cannot know when to throw that error. Maybe your result of find() will get pages added at a later stage of the process, which wouldn't get called if pw would throw an 404 error right after the find() call. $list = $pages->find("stuff=selected, limit=10"); // if list is empty and it's not the first page if(!$list->count() && $input->pageNum != 1) throw new Wire404Exception();

Your problem isn't the selector, but the if condition. $news_list is an object of the class PageArray. Objects always equal true in php. You need to check if there are entries in that object. $news_list = $pages->find("template=news, sort=name, show_in_slide!=1"); if ($news_list->count()) { echo "There is at least one news not shown in slide"; }else{ echo "All news items are shown in the slide"; }

You're page field is preset with fixed pages to choose from, so I'm not sure what exactly you want to compare here, but to do compare a page (from the field) with a page(from the selector) just use this: $pageSelector = $pages->find("…"); $pageField = $page->myPageField; if($pageSelector->id == $pageField->id){ // We have a match }