raydale

Yes, I like this approach very much. Again, this seems to be an elegant way to handle the flexibility that ProcessWire provides. It's obviously going to take knowledge of how to use ProcessWire by the end user to be able to map the fields correctly, or a range of themes could be accompanied with an install profile. Either way we could achieve standardisation and flexibility all in one. A profile could be created by a theme author specifically as a starting point to test the various themes they supply out. Currently this approach gives a lot of possibilities and permutations in creating themes. It also gives ProcessWire CSS Zen Garden type functionality whereby installing the basic standard profile and then switching themes could provide all sorts of different looks to the frontend. All without too much complexity added, either in the theming system itself or in the individually installed themes. Finally, a designer could use a theme module as a base, copy the files from it into the 'templates' directory. Uninstall the theme module and then use the files they have copied across into the templates folder as the basis for a site that they work on top of. This is then a very nice method for designers to learn how to use ProcessWire with a lower barrier to entry. Even better would be to have a system of overrides with the current theme still installed This is an interesting concept and could help to make a theme more universal. However, would this not bring more complexity and bloat for the end user and theming system? This is also similar (in concept) to how Drupal works as well with multiple and potentially redundant template files that can be overridden. It provides the possibility of a theme being able to cope with new fields and field types being used after initial install. However, it comes at a cost of having to provide field template files for so many different permutations and therefore much higher complexity and overhead when creating the themes.

I couldn't agree more with Apeisa here. It comes down to a choice: if you want ProcessWire to become popular outside of that group of traditional developer types then you have to appeal to those with 30 minutes to spare and low technical experience. If on the other hand people here are happy to let ProcessWire grow slowly, organically, continually appealing to more technical mindsets then it is doing a great job already and should simply continue on that path. There is nothing wrong with either route and it all comes down to the expectations of the community here. One word of warning about expectations though. I watched the Drupal community grow from version 5, 6, 7 onwards and the bitterness that resulted within the community when WordPress started to dominate the market (around Drupal 6) was palpable. The Drupal community believed that they had a far better system with more flexibility and inherent security, but they were very scathing of the fact that WordPress (sometimes described as 'HerdPress' within the Drupal community) became so popular and Drupal didn't. My point (eventually) is that until very recently (with the advent of Drupal 8) the Drupal community missed the reason as to WHY WordPress was dominating so. They thought it was marketing, but really, it wasn't. The simple reason was that Drupal was engineered for developers and encouraged very little involvement from the design community. I couldn't count the amount of times designers would attempt to engage in the forums and request a simpler theming system only to be sounded out by the developers there - sometimes very aggressively. WordPress on the other hand encouraged the design community and became easy enough for designers with traditional design mindsets to pick up. WordPress actively engaged that audience and a theming system was built that partially catered towards them. Combine the WordPress theming system and an admin interface which is one of the nicer ones to look at and use and you have a package that appeals very strongly to a lesser technical mindset. The whole concept of growth and whether to cater towards the less technical mindset then comes down to choice and expectations. If ProcessWire continues down its current path, it will build a very strong following of developers (and some slightly more technically minded designers). However, it will never grow beyond a certain scale and will always be less popular than many other choices already out there. Again, that's okay if the intention is there to focus on that audience to the exclusion of others. However, the market out there for the designer / CMS administrator type of profile is vast and much larger than that of a development centric audience. It's a simple truth and one which would need to be catered for with better turnkey solutions if ProcessWire wanted to better engage the non technical mindset. The community would also need to welcome them (which I don't think will be a problem from my experience). If ProcessWire wanted to engage and grow its audience to compete with the 'bigger' and more popular systems it's already (in my opinion) in a much better place than Drupal to capture a less technical market. It's API is streets ahead in terms of simplicity for frontend development and it's community is less hardcore. However, some things need to be more readily available to cater towards the designer type who isn't a frontend specialist. A theming system is central to that need (again, in my opinion). The traditional designer mentality is one that is only very slowly moving in a more technical direction (in a typical sense). The Photoshop GUI and knowledge of CSS being as technical as it gets for that type of user. Therefore, having pre-built examples and tools that are easy for a designer to iterate on are essential. Having a packageable theming system would not only help others coming from other systems with ProcessWire, but would enable designers to have less complex starting point to suite different needs. I work with a number of designers coming out of university who still have poor technical skills, they barely know Photoshop to the level that is needed. ProcessWire is unfortunately too great a step for them. Whereas WordPress is easy for them to pick up. In WP they can install a theming base and then iterate from that quickly, they also have plenty of how-to guides catering towards their mindset. Most of the time, they will use a theme base as a starting point for their PHP and XHTML markup and CSS, completely altering the CSS and some of the XHTML, but barely touching the PHP 'voodoo'. However, after a few months they start to become more comfortable with PHP and will then iterate on that layer as well. Then, a frontend developer starts to emerge! They are now very comfortable with WordPress because they have had success with it. Nico's solution I think is perfect for the ProcessWire community. Simple, elegant, potentially very powerful and more importantly optional. When this reaches maturity, you could combine this with a series of tutorials and profiles engineered towards a designer mindset and you have a very simple way to better engage that type of audience and attract them to the ProcessWire project. As a by product of catering for that designer mindset, you then also have the potential turnkey solutions that an even larger audience profile thirst for...

Hi Nico, this is a very interesting development and perfect for a particular use case I have in mind right now. Your solution is very simple and elegant so far. I see your problem with regards to ProcessWire's flexibility and I think the ProcessMigrator json file would be the best approach. How possible would it be for each theme module to have its own ProcessMigrator json file that could be used (as an optional step) to import fields used in the template? In this scenario you would install a particular theme module and then decide on whether you wanted to also install its field sets that guarantee a workable setup (or a bit of a blank slate). Using a system like this would enable theme authors to create truly packageable themes whereby they can create themes for specific use cases and be able to guarantee that the fields are available in the system. The difficulty would obviously be that you're giving a lot of control to the theme modules and something would have to be done to ensure that a users site is decimated or bloated by the newly installed theme. In other words the theme module could easily provide too much unnecessary and complicated functionality as with other CMS options out there - yes, I'm looking at you WordPress. Another interesting possibility would be to enable a system of overrides somehow, whereby any template files could be overridden from the installed theme module by creating an equivalent file in the templates directory in PW. This would then allow customisation of any theme modules and allow the theme module to be updated without losing the customisations. Or instead of this approach, a child theming system could be created where a child theme module could have a parent theme dependency, again, allowing a child theme to override the parent one. Just a few thoughts

Fantastic functionality Ryan. Will the field dependencies work within repeaters?

Thanks Soma, I will take a look at your module and attempt to tackle a module. I am not a developer (but learning), so I may have some questions when I get started if that's okay?

Thanks Ryan. Judging by your response, this would even be complex to build in a module due to the vertical sorting?

Thanks for the response Kongondo. However, no, that's not quite what I am looking for. You are pre-setting the individual field widths within the repeater in your example. What I am looking for is to be able to set the width of the repeater itself - dynamically via an input field that can be selected by the content manager. Below is an illustration of what I mean. Repeater Columns #1 and #2 have been dynamically resized by the the Grid Width field paramaters chosen. They take up 50% of the available width because '4 Columns' have been chosen for each of the Grid Width fields (this particular example is arbitary and is based on a maximum 8 grid width, but could equally be litterally a percentage input).

I am looking for the best approach enabling control of the repeater inputfield widths in the PW admin. I would like to drive the width of an individual repeater field (width and float for a more grid like layout) by a field within that repeater. For example, a repeater might have the following fields: title body images grid_width I would like to drive the repeater width in the PW admin by 'grid_width'. So, if the field 'grid_width' had a value of '50' the repeater field would have the following CSS - 'style=width: 50%;' applied to it's containing 'li' element. In this way a visible grid of repeater fields could be built with custom control over the repeater widths. This grid could then be more of a wysiwyg of how the repeater fields would work in the frontend and would be much easier for the client / content manager to predict everything would look.

Hey all, I thought this might be useful for anyone who uses preprocessing tools (like the excellent CodeKit: http://incident57.com/codekit). I came across Prepros the other day: http://alphapixels.com/prepros/ I always used CodeKit up until recently. However, it's only available for mac and recently I have had to dip my toes into the waters of the dark side again with a PC laptop I needed something that would work cross-platform (Prepros works across PC, Mac and Linux). From what I have seen so far Prepros is growing quickly, free, supports nearly every type compiled CSS, has real time refreshes and works across platforms.

Hi Barry, Are you saying that you still can't reorder the posts in the admin? I have a test version of the blog profile (latest version) running in PW 2.3 (stable). If I Edit the 'Blog Posts' page and set 'Children' > 'Children are sorted by' to 'Manual drag-n-drop' (under the 'Sort settings'), then reordering works fine for me. However, this doesn't change the render settings for the frontend of the site (which are still rendering '-date' sort order irrespective of the order in the admin area). You can look into 'blog.inc' under the function 'renderPosts' to change this. Set 'sort=sort' instead of 'sort=-date' to ensure that the manual ordering in the admin area is respected.

I've just seen this. Great work and thanks Ryan!

Thanks for pointing that out Soma. So, I guess there is no change (from 2011)?

Thanks fmgujju, it's not just me then! I have a site profile setup with over 30 templates and 10 users where all permissions and roles mapping have disappeared.

Hi, are the user permissions / roles and template permissions supposed to be exported / imported as part of the profiles? Every time I use a profile I have exported everything works very well apart from any users & permissions etc. which import with no roles assigned to them. The roles are all imported fine, just the users roles are not mapped properly. The templates also seem to remove any access permissions. I am using PW 2.3 stable. Can anyone confirm this?

This is great! PLEASE post a case study on this when you get time. A case study on this could be especially useful for devs/designers evaluating WordPress or ProcessWire.