kongondo

Not a good idea though without limits...can easily overwhelm the server if lots of descendants: return $page->find('');// will find all descendants

I am thinking of changing the way variations + attributes are created and applied. Currently, these have to be typed whenever one needs them. For different products that share an attribute (e.g. 'Red') but not necessarily a variation configuration, all that typing is repetitive. For instance, the colour Red means the same thing irrespective of whether it is a Car or a T-Shirt or a Phone. If you have all these products for sale, you should be able to just select colour from some list you previously typed and be presented with all colours from which you can select which apply to your product. Meaning, at the product/page configuration level, you will first have to select the variations you want, e.g. Size, Colour, Material, etc....then select the respective values/attributes, e.g. Yellow, etc. Small, etc.

Hmm. That's an interesting observation. I am curios that no one else (as far as I can tell) has had/reported a similar experience. I wonder if it has to do with your setup?

Yes, that's CSS issue. Try and see if it works . Are you using the demo template files that come with blog or did you create/or are using a blank blog-post.php? If the latter, then please have a look at the example demo file. It is a bit redundant to have the code you pasted (which is an example code I gave for some other context) within a blog-post page itself (i.e. redundant to use it in blog-post.php which is the template file for a single blog post).

Hi @suntrop, I know you told me that you'd already found a solution for your project. If you have the time though, I'd appreciate any thoughts you have about this new module (offering variations and attributes functionality) that I am developing. Thanks.

@Jeff C, Welcome to the forums and ProcessWire . The usual way is to use page fields (page reference fields). Please see this content:

Yes, e commerce being the most likely use for this module. Just to be clear for the sake of others, technically, these are subfields. E.g., price is a subfield (meaning a database column in a FieldtypeVariations field [technically a database Table] which you access as $variationsfield.price, similar to $page->image.description). Back to your question, this is a planned feature (although code is already in place). Please note that, in respect of these subfields, there are no plans to include anything as near exhaustive as what Table does. Meaning, these will likely be limited to TEXT, INT, FLOAT, etc fields, but not complicated Fieldtypes such as Page fields, Repeaters, etc. Yes, as many or as little as you want, pre or post-field use. For instance, start with price (default but in future versions one will be able to remove the subfield), then later or at field configuration add an SKU subfield, a discount subfield, some text subfield, etc.

Introducing Variations, an Input- and Fieldtype for product variations and their attributes. Product variations is a topic that has been coming up now and then, especially in the recent past. This module seeks to fill this gap. Though it's in its early stages of development, it is already functional and can be used as is. I decided to make an early announcement (modules development forum) in order to get early feedback from potential users. The module is an alternative take on how variations can be built for a product. Imagine the ubiquitous T-Shirt. The product could vary by ...Size, Colour, Material, etc...These variations could in turn have internal variations, i.e. attributes....so, Size [Small, Large], Colour [Red, Blue]...etc; you get the drift. The usual approaches to building variations have been either to use Multiple pages, Repeaters, Page Table, Table or Matrix (limited to 1x1 variations). In this module, we do it a bit differently. First, the variations occur not at the Field level (meaning all product pages would have the same variations and attributes for each template) but at the page level. Secondly, there are no multiple pages for each variation and/or attributes; a product is a single page. The variations and their attributes are defined by site editors at the page level. Once a variations configuration has been defined, it is applied to the page and all possible combinations are generated (i.e. the Red,Small,Cotton; Red,Large,Cotton, etc) in the Inputfield. There is no limit to the number of variations and attributes that can be defined, although you will be amazed at how quickly the combinations grow! Prices are entered for each combination when editing the page. Combinations without prices are not saved to the database. Please note that prices cannot themselves vary at the page-level. Meaning, you cannot have ONE variation configuration that has different price inputs per product in the same FieldtypeVariations field. The module ships with an API for outputting variation combinations in the frontend. Search, database and in-memory work as normal in the frontend. In the backend, DataTables provides a nice paginated, filterable table. Prices can be entered on any pages (of the table) without loss of data (meaning you can enter prices on page 1, scroll to page 10, enter more prices, filter or search the products table, enter more prices and finally save; no data will be lost). I still have a couple of ideas and plans pending but would love to hear from you, thanks. Below is a short video demo of the module in its current state. Things may/will change, both UI and features. Btw, the Fieldtype, although primarily targeted at commerce applications, is by no means limited to this. Other uses requiring combinations of whatever number of variables are very much within the remit of the module. Planned/Hoped for features Import/Export product variations and attributes (Excel, etc) Full integration with Padloper (I will have to discuss with @apeisa) SKU fields for each product variation Add/Remove extra subfields, e.g. multi-currency prices (currently there is only 1 input for each product variations' price) Product variation images? Etc... Please not this module is not related to this other planned module (but it may eventually). Sneak Peek Demo

Welcome to PW and the forums @TorLan. Yes, that's how it works. It's for outputting a date in the frontend. So, there's is no timepicker in the frontend with this field.

This will soon be the 'most up-to-date' method . Admin themes in ProcessWire are modules. There is no way to directly edit the theme in some editor within the admin to get the results you want. To change stuff and to make sure they don't get overwritten, you can copy and rename (including class rename) an admin theme module and edit it to your liking and install that. I stand to be corrected but I think you can install a custom admin theme that way, i.e in /site/modules.

What @LostKobrakai said. Just to expound on it. Your aim is to find pages [in this case 'coaches'] that use a particular category [in this case the children of 'Provinces']. As a by the way, it is also possible to do the inverse, i.e. find the 'categories' that a page uses. In that case, what you would be doing is just looping through Coach 1, etc, and outputting the category pages in their coach_provincie [i.e. the page reference field]; but I digress. Back to the question at hand. You do not need (can be dangerous, not user friendly, etc) code in your editor You do not need multiple templates for your provinces, i.e. Limburg, Drenthe, etc. Suggestion for your templates: Coaches:// template 'coaches' -Coach 1// template 'coach' -Coach 2// -ditto- etc. This is how my references tree looks like: Provinces:// template 'provinces' -Limburg// template 'province' -Drenthe// -ditto- -Utrecht// -ditto- Which coaches travel to this province? When viewing a particular province page, e.g. /provinces/limburg/ and want to find all coaches that are available for this province, all you need is to add Lostkobrakai's code above to the template file 'province.php' <div class="row"> <?php $coaches = $pages->find("coach_provincie=$page->title"); foreach ($coaches as $coach) { echo '<div class="col-md-6"><a href="'. $coach->url .'">'. $coach->title .'</a></div><div class="col-md-6">'. $coach->coach_locatie .'</div>'; } ?> </div> That code will return coaches that have 'Limburg' [the $page->title] in their page reference field (the one with the checkboxes - 'coach_provincie'). Which provinces does this coach travel to? On the other hand, if you want to know which provinces a coach travels to, e.g., Coach 1, (i.e. this URL /coaches/coach-1/, all you need to do is something like the below in the template file 'coach.php' foreach($page->coach_provincie as $destination) { echo $destination->title . '<br>'; } That's it .

Glad you sorted it out. Question is, were those permissions changed between Friday and Tuesday? If yes, how and by whom? Hmm..

I am a bit confused here. Do you mean AND and not OR? I.e. do you want normal posts to open as /mysite/blog/blog1/ AND news posts to open as /mysite/news/news1? OR you are happy with either? If AND, then you will need URL rewriting as explained here (quite advanced code) or similar. If you mean OR, then just rename the page 'Posts' to whatever you need, i.e. either 'News' or 'Blog'. I am not sure I understand this either. I assume you mean clicking on the sub-navigation on the right-hand side (in the demo blog template files)? If yes, that navigation is built using the method renderNav() in MarkupBlog. You might have to create your own custom navigation in that case.

To be honest, am totally clueless. I don't still get the reason why you should have code in your editor. Maybe if we saw a page tree and a bit more clarification we'd be able to advise better.

Hehe...

No. I am looking at this: From your code, it seems the 'difference' is based on these pages' children? You can output the menus in the single template file based on the page that is being viewed...i.e. $page->children; Maybe I am missing something?

Do you really need to generate menus in the text area? Why not in the pages' template files?

Exactly!

As you can probably tell, I am pretty ignorant about multi-lingual features of ProcessWire . I don't have time to investigate right now so will appreciate any thoughts/pointers. My guess is that in a multi-lingual site, ProcessWire will automatically duplicate fields attached to templates for each language? If that's the case, then implementing your request becomes much easier.

Madness! Would you get into one of these?!! http://www.bbc.co.uk/news/technology-38967235 https://www.engadget.com/2017/02/13/ehang-184-passenger-drones-dubai/ Aah, just letting off steam..

Welcome to the forums @looper . You'll need to upgrade to at least ProcessWire 3.0.46 for that feature according to the docs here.

3b. Or PHP's DOM Parser .

Yes...it is.

Aah, good to know .

Actually, output formatting is always off in a module. If output formatting is off, Image fields will always return an array, no matter your settings. So...first(), last(), eq()....are your go to guys...