LostKobrakai

Having an empty install() method prevents the automatic installation of process modules, so there should either be a parent::install() in it or the selection should only allow either un/install methods or automatic page creation. Also the placeholder for page.parent config suggests "name=setup", while the field should only consist of the name itself. Implementing ConfigurableModule is only necessary if you're using the old static implementation. The "include configuration page" is a separate file, which does work no matter what the module implements.

$page->listings returns a PageArray and PageArray::find doesn't work out of the box with pagination. Either set the start/limit/total values manually or use $pages->find() or $page->children(). Both of those will set these values automatically. Edit: Quick hack around. $listings = $page->listings->find("limit=2"); $listings = $pages->find("id=$listings");

Recursive hanna codes is mentioned already a few time in this topic. There's an open pull request on the github repo, that adds support for that, but the official release doesn't have that right now.

Just like MySQL is the database of choice apache is still the widest spread http server. Nginx is quite rapidly rising in popularity, but in my impression it's mostly used by node environments or for complex server / routing setups. While there are already topics here about nginx settings to run processwire, the people running such complex setups should be able to make nginx do the same things like the apache .htaccess rules or even just place the apache behind nginx. If I get the facts right here then only ProCache is deeply dependent on an apache setup. While these should be the reasons why there aren't other options by now, a nginx configuration would be a nice addition to the core. Supporting another http server should be an easier thing than supporting other db's which are also on the wishlist.

That's not a number that should hit any limit. I forgot to ask about the used processwire version and potential 3rd party module usage on that pages / repeaters.

You could use the DynamicRoles module to do so or write a custom hook, which extends Page::publishable to allow the editing of tags.

It may look a bit special because of the lower case spelling but it's the GET variables you're using mostly with forms. Everything after "domain.com/?variable=value".

Static would mean, that nothing may change in future updates. Even layout changes cannot happen at a later stage, so I'm not sure if this can be sufficient.

Create two files, which would collide only by case. See if the second one throws an error.

Then try to save not only the "children" but also the page which holds the pagetable. The orphaned pages message appears if there are children matching the pagetables settings, which are not part of the table itself. Normally pages created by the pagetable add button should automatically be saved to the pagetable, so I would investigate this further, even if additionally saving the parent page will fix this.

Are you adding the pages as children or via the pagetable?

Keep in mind 2.5.3 < 2.5.20 because 3 < 20.

The entry is in the .htaccess because files in that folder and of those types aren't normally supposed to be visible to users. They are part of the rendering process, but that's going through the index.php and therefore direct access isn't necessary. By default you wouldn't want users to be able to open html snippets directly, because they should only see the whole website. Polymer is a whole other way of templating and therefore needs direct access to partials. Edit: Additionally .php/.inc/.tpl will most likely hold php code which is dependent on the processwire bootstrap process and would error on direct access. .html is the only one which can potentially be independently useful.

Is $homepage defined anywhere? It's not a variable available by default. Most of the time users use this in their _init.php, which can be prepended to all templates: $homepage = $pages->get("/");

If you do need 9 different settings for the fields then sure, make each on an own field.

PageTables with a hidden parent page are the way to go. Otherwise the pages will get appended as children, where they are even more obstructive. The only other alternative would be repeaters, as long as it's only a single template. There are lots of topics here in the forum about managing building blocks, where you can find more in depth conversation about the topic.

$page->body does only display the body field. There's nothing that would automatically display all fields of a page in a reasonable manner. You need to layout the presentation of the different fields by yourself. $page->body fetches the body textarea, while $page->banner will get you your banners. Maybe you should have a look at the different tutorials here: http://processwire.com/docs/tutorials/ Especially the one about structuring template files.

It's because of the caching. This will be resolved when it's going to launch fully.

You cannot just echo the image. You need to echo the url property of the image. // No need to save the image in a variable if you don't need it multiple times <img src="<?php echo $page->images->get("name=filename.png")->url; ?>"/> // else <?php $image = $page->images->get("name=filename.png"); ?> <img src="<?php echo $image->url; ?>"/>

Why would they change? Images inside the template folder are part of the layout and mostly of the "put it there and leave it" fashion. Dynamic things should really be stored in image fields. There made for that.

If you're talking about static images (not part of an image field in the backend) then have a look at the $config->urls->somethings. // full url: /site/templates/img/static.jpg <img src="<?php echo $config->urls->templates."img/static.jpg"; ?>" alt="Some image" /> If not then like this: $images = $page->images; // If multi image field foreach($images as $image){ $url = $image->url; // echo html image tag } $image = $page->image; // If single image field (max number == 1) $url = $image->url; // echo html image tag

Yeah, they get redirected to this url: http://new.korona-licht.de/produkte/#!systemprodukte Just checked on another computer and had the problem as well. I did just change my header redirects to $session->redirect() and this solved it here.

Yeah, just scrolled down at a "reasonable" speed and noticed only 2 or 3 blank boxes, while before most of the boxes where empty.

Not that I'm aware of, that's why I'm not using lazy loaders. For me it's enough to use the srcset/sizes to serve small images by default and leave the rest to the browser.

You're mostly correct. About the WP Loop comes this to my mind: http://www.designer-daily.com/wp-content/uploads/2012/08/query_functions.jpg. ProcessWire simple uses php functions like foreach, implode, explode and since a few versions special convenience functions WireArray::implode & WireArray::explode, which work similar to their php counterparts but look a little cleaner. No need for a strange loop object if you can simply iterate everything thats at least array like or even an array. Regarding the calendar / ecommerce thing. It's true that there aren't many ready made plugins out there, but at least for ecommerce it may even be better to use a dedicated ecommerce cms.