Leaderboard

Hani, ProcessWire will scale pretty infinitely in terms of pages, but not in terms of fields or templates. The same can be said of databases in general–you can have millions of rows in a table, but probably don't want millions of tables. I would say you've gone beyond what may be practical for long term use and maintenance of the site. At least, I have never tested ProcessWire with any more than 200 fields (and I thought that was an insane amount). I would be curious why so many fields are necessary? It might be good for us to get a list of all the fields, which may lead to some good suggestions on alternatives. But this is a situation where I think you might really benefit from making your own Fieldtype and Inputfield combinations. It is surprisingly simple to do, and can represent any DB table, no matter how many columns it needs. There is far less overhead in having a custom Fieldtype that represents a table with 100 columns, than there is in having 100 separate fields. Have a look at Adrian's new FieldtypePhone/InputfieldPhone module for a good example of how to represent a DB table with a Fieldtype. Some other options I can think of relate to ProFields, a pack of modules I've been working on to release soon (probably as commercially supported like FormBuilder and ProCache). It includes FieldtypeMultipler, FieldtypeTable, FieldtypeTextArray and FieldtypeTextareas, among others. These enable you to have a single field that can to represent any quantity of inputs. Though they all do it in a little bit different ways. FieldtypeMultiplier lets you take any other Fieldtype (that isn't already multi-value) and turn it into a multi-value field. FieldtypeTable is a multi-value compound type that lets you keep a user-defined combination of fields contained in a group… not quite as powerful as a repeater, but it's only 1 field and has far less overhead. FieldtypeTextArray lets you have a defined quantity of inputs for any text field… like say you needed a field to represent 3 email addresses, for instance. Lastly, FieldtypeTextareas lets you have 1 field that can represent any number of named textareas while having them all be searchable from the same field. For example, you could have a single field called "content" that contains separate inputs for body, sidebar, summary and about_the_author or something like that, but they only consume 1 field, accessed via $page->content->body, $page->content->sidebar, etc. All of these Fieldtypes/Inputfields are aimed at really reducing the overall quantity of fields necessary to represent lots of data. I developed this set because I had a site with lots of similar fields, and this group of modules helped me to reduce the quantity of fields by more than 70%. However, these aren't ready for production use, so it may be a little while before I have them ready. But if you'd be interested in helping to beta test them, your use case might be about perfect.

The basics of programming I learned from Filemaker Pro. (That sounds weird) 13 years ago I started as freelance Scaffolder in in the stage building business. On that time, I really messed up my book keepings and I needed a simple but effective Invoice system. In that time I build occasionally websites with pure HTML, wished to use some PHP, but couldn't wrap my mind around it. Then I found Filemaker. I start building the system and came across a totally new terrain for me (programming). I came across database relations and I really needed to script it. The if statements and database relations pilled up, but at the end I had a simple and effective Invoice system. This is where I learned some basics of scripting, after that my mind was set, and I could start with PHP.

Hey all, Here's a demo of what I've built. It's become my primary bookmarking system: I didn't demonstrate it in the video, but this system works amazingly on a mobile device too. It's so easy and quick to pull up stuff I want to read when at a coffee shop or have a few minutes to kill when on the go. I found Diigo's Android App very limiting in comparison, especially since it doesn't allow you to view all of your bookmarks on the mobile app (last time I checked). I have no plans as of yet to release this, but I may in the near future if you are all really interested. There are features I still want to build out as well as a lot of code cleanup and security measures that need to be implemented. Enjoy! Jonathan

Hello All, I am Senthilkumar, Technical Author from www.unixmen.com website. Recently i installed and tested ProcessWire On CentOS 6.4. It's worked for me at present. I would like to share the how-to document in ProcessWire Forum. Hope it will useful for ProcessWire users. Here is the link: Install ProcessWire CMS Using LAMP Server On CentOS 6.4 Regards, SK.

Beautiful work @jlahijani! Great job with the screencast too–I need to hire you to do my screencasts. Unless you've got other plans to produce it into an SAAS app or something, you should definitely release it. I think a lot of people would find this very useful both as a great tool to use and an impressive example to learn from.

What you think how much time I have spent with try and error and so any coder living except maybe Woz. It's part of the business and if one is not willing to try he get nowhere. When I make designs it's practically the same.

Select Multiple Transfer Multi-selection Inputfield module for ProcessWire using the jquery.uix.multiselect plugin by Yanick Rochon. This Inputfield provides similar capabilities to asmSelect but in a very different way. The usage of two separate lists may be more convenient when needing to select a large quantity of items. Like asmSelect, it also includes support for sorting of items. Unlike asmSelect, it has a built-in search field for filtering. It can be used anywhere that the other ProcessWire multi-selection inputfields can be used. Download ZIP file Modules directory page GitHub Class (for auto-install): InputfieldSelectMultipleTransfer Important Installation Notes This module is installed like any other, however you will need to take an extra step in order to make it available for page selection. After installing this module, click to your Modules menu and click the core InputfieldPage module to configure it (Modules > Core > Inputfields > Page). Select InputfieldSelectMultipleTransfer as an allowed Inputfield for Page selection, and save. Now you should be able to select it as the Inputfield when editing a Page reference field. For obvious reasons, this Inputfield would only be useful for a Page reference field used to store multiple references. (Note that this video is showing this module in combination with field dependencies and dependent selects (something else brewing for 2.4 but not yet committed to dev).

Is anyone here a heavy bookmarker like I am? Typically I'll get most of my news from Hacker News and Slashdot, followed by some great blogs on a daily basis. I usually never have time to read an article in depth when I first come across it, so I'll bookmark it for later. Or, if I quickly need to get up to date on some topic, I'll do a search (usually by tags) and familiarize myself with important stuff I've bookmarked in the past. After having used browser native based bookmarking (Firefox and Chrome), then Delicious, then Diigo, then Pinboard and becoming frustrated by all of them for various reasons and limitations, I've decided to roll my own little single user (and non social) bookmarking system with ProcessWire (with Bootstrap 3 as the frontend framework). It's still a work in progress, but it takes the best of all those systems with my own power features. It also utilizes ajax for certain actions. I'll need to create a Chrome extension to tie it all together. I have to say however, after working non-stop on it for hours on end and not being able to think of anything else, it's looking slick. Damn you ProcessWire for making this so enjoyable. Jonathan

A responsive and minimalist photographer portfolio. http://mikael.siirila.net/ (and if you like the photos, follow me at http://www.facebook.com/mikaelsiirila/) -- Mikael

Hello all, I haven't been around for quite a while, but I'm still trying developing stuff for my classrooms (I'm an English teacher) and this time I'm a little stuck even before starting... Let me explain : I've used ProcessWire for my English site (FLEnglish : http://flenglish.tuxfamily.org - if you're curious) and I just loved it (not my site, ProcessWire ;-), and I appreciated the community help a lot) So here I am again with a 'new' project and my questions : I'd like to implement some kind of RPG Game (in the style of HabitRPG) for the language classroom. Actually, it's a lot easier than HabitRPG since I'm interested mainly in managing the score part of the game. I'd like the kids to have a character (no images for the moment, just a name), and scores for Health Points, Experience, Level, Gold Coins) and according to their achievements in class, the scores improve and so on. The idea is that I'd need a tool quite handy to manage because I have many pupils in classes and no time in class to manage all this. Let's see an example : All kids did their homework. They all get +3 experience and 5 gold coins. I don't want to spend 10 minutes going over each pupil's name and adding their numbers... I thought of the Skyscrapers demo site for a start : yes, I could manage students this way, having field for XP, HP, GC and so on (this is what I started doing actually). But then,I can't manage pupils' results 1 by 1 going through the Admin page in PW. So I thought of using Javascript to avoid having to validate a page on which I would have 120 fields to update according to the task succeeded. That's when I started thinking trying to continue learning AngularJS, but I was unable to make it work along with PW... (I get a 403 error when routing to the view template_ I put everything in /site directory, maybe that's not a good way). Anyway, this is quite a mess in my head at this time even though I would like to try and do something this way. If anyone here could give me a possible thought about this to give it a start : could PW be useful for such a task? To be honest, I would love to use PW for this since I would like to be able to merge this score thing with my site already using PW (and why not imagine 'users' being able to log in to see their scores and so on...?) I'm afraid I'm being extremely complicated on that. Let me rephrase it : - Could I have such a system for scores management using PW ? - Could I have a user interface quite handy to update scores easily using PW? In brief, what do you think? I hope reading this was not too much of a burden. Thanks for your help! Celfred.

I don't want to say anything that implies we aren't moving forward. The worst thing for software is to be stuck in time. But I do believe our API is a constant that will transcend versions. In fact, the term API implies a level of consistency and predictability that I take seriously. If for some reason we need to change parts of the API in order to move forward in the future, then we would version it. Meaning, you'd still get the old behavior if your $config->apiVersion was not up-to-date. Though I've not yet seen any reason for API changes, just additions. Believe me I don't want to create upgrade hassles for myself or anyone else, though I don't typically upgrade existing PW installs unless the client needs something from the newer version. Libraries like jQuery can't afford to version their API because they have to be as tiny as possible. But we can afford to do that, because source code size is far less of an issue for a server side application than a client side one. But this is all theoretical, as I mentioned we have not yet come across any reason to change the API. I agree with Pete.

If the users are all editors, it's true that you won't want to use any automatic caching (and may not be able to). But you can always use MarkupCache to cache elements that you know are ok to do so. In your case, I would try to isolate the bottleneck. Wrap statements like this around your significant sections of code, until you track down what is causing the slowdown: $timer = Debug::timer(); // .. a block of code you want to measure $this->message(Debug::timer($timer)); It'll tell you how many seconds the block took to execute. If this is outside of admin context, you can replace the $this->message() with an echo or something else, anywhere that you can see the results. Once you find the source of the bottleneck(s), you may be able to optimize them to improve the speed. Often times there is just an inefficient block of code that can be fixed. But if that's not the case, you may want to then look at MarkupCache'ing them. $cache = $modules->get('MarkupCache'); $out = $cache->get('your-unique-name', 86400); // 86400=num seconds age if(!$out) { $out = SomethingThatTakesAwhile(); $cache->save($out); } echo $out; I don't know about that context, but an opcode cache can be very helpful. If you can't use an opcode cache, I would make whatever changes are necessary so that you can. No PHP 5.4+ should not break anything. In fact, I think you'll find that just switching to PHP 5.4 provides a nice speed boost in itself (at least it seemed like it to me). I am running PHP 5.4+ on all of my own PW installs now.

Thanks Horst! Your knowledge and code for working with images is fantastic! I will pull this into dev soon. I need to get caught up with my forum messages, and then hoping to catch up with my GitHub messages next week. Separate PR is fine. For stuff like this, I generally make sure I understand everything that gets committed by re-typing the lines myself or at least going through them individually on a copy/paste, until I understand it in full. It takes longer to do this way, but it ensures I can properly support it in the future if a question comes up and you are on vacation.

800 fields!? You're crazy This of course would be a important factor. I think it would all work but you'll need a strong server to handle that much fields. Even though then it may can handle it it would be still quite a load on server. So the question would be why 800 fields (crazy) and a template with 400 fields (crazy) is a -bit- overkill. I'm not sure how it comes you need so many fields on one page. Unfortunately I don't see much that could be done in the list fields admin that renders all fields as a list, since now it used a lot of filtering and grouping by labels it can't be easily paginated or something. Only thing I see would be to create custom fields list admin that is limit to 50 fields, or use a search (admin hotkeys can do this too) to get to a field. I'm also thinking if it wouldn't be possible to simplify this. As diogo mentioned you could maybe serialize the data some. After all this sound a lot like a data heavy application (really heavy) that maybe too much to go the PW way of creating all and every field as a field and attach it to a template. This sounds more like a custom application that could use a custom database or tables. What I would consider is, as you said, to build some custom tables for the data and use SQL queries. Or what you could try is creating some custom simple fieldtypes that store groups of data fields to a table at the end. Like a field stores prename,lastname,address,tel etc. You'd then have less fields and still could use the API and selectors. If you need help we are here to guide you. What I also thought is (but don't see the full context) why add 400 fields to a template and not split it up to many templates and use hierarchy in the tree with child pages to store data. But then still you'd have a lot of fields. Some of the larger sites I have +-100 fields and I think it's already quite a lot (some are alternative fields _de, _fr, _en etc). So if you could let us know more details of how it comes to you creating 800 fields it may help to understand and find alternatives.

hm, 400 field in one template sound really like a lot. Maybe you could optimize those templates by joining all those fields in one. If you're are not planning to use most of them for making searches and you only need to spit them when they are called by a page, crate a textarea and make a list with the info from all those fields: field1: "content" field2: "content" field3: "content" ... To present the content of this field, just explode it (but not literally, please)

Heh, I also often feel like I'm banging my head against a brick wall when I code. But I guess one day you do break through it. Side note: I actually haven't had any success with curly brackets either, until reading this post. I don't know why, just whenever I used them they never worked until trying it again now. So guess you're not the only one!

Yeah also wanted to mention but thought not overkill the thread. You can use also use the new pw log functions. $log->save("mylog","test") // will save test to mylog.txt

Dude, this is amazing! Good job! The interface is great! You logged in and I was expecting to see a tree, then boom! I see a totally diff app. . I like what you have done with this and taking the time to demonstrate it. It's nice to see how others have leveraged PW as a framework to build applications. We've been having this discussion whether PW is really a framework...well, there's your answer! I'd be interested to have this released, not so much that I'll use it (am not a heavy bookmarker - never used Digg and the like [gasp!!] ), but as a learning platform, inspiration and showcase of what PW can do. Of course, the decision is yours. Irrespective of whether it is released or not, am really impressed. Well-done! Cheers/k

Phone Number Fieldtype A new fieldtype to enter phone numbers with 4 integer values for country, area code, number and extension and format the output based on predefined or custom options. StyledOutput The most common usage option will be: echo $page->fieldname //eg. +1 (123) 456-7890 x123 This provides a fully formatted phone number, based on the output format chosen from module's configuration page, or with the format override option (if enabled), when entering a phone number on a page. This is a shortcut that produces the same output as: echo $page->fieldname->formattedNumber //eg. +1 (123) 456-7890 x123 Alternate styled options are: echo $page->fieldname->formattedNumberNoExt: //eg. +1 (123) 456-7890 echo $page->fieldname->formattedNumberNoCtry: //eg. (123) 456-7890 x123 echo $page->fieldname->formattedNumberNoCtryNoExt: //eg. (123) 456-7890 echo $page->fieldname->unformattedNumber: //eg. 11234567890123 echo $page->fieldname->unformattedNumberNoExt: //eg. 11234567890 echo $page->fieldname->unformattedNumberNoCtry: //eg. 1234567890123 echo $page->fieldname->unformattedNumberNoCtryNoExt: //eg. 1234567890 Of course the actual output is determined by the selected format output Raw Output You can output the values for the component parts of the phone number like this: echo $page->fieldname->country; echo $page->fieldname->area_code; echo $page->fieldname->number; echo $page->fieldname->extension; Output for mobile compatibility To get iOS and other mobile platforms to recognize numbers and be able to automatically dial them, use something like this: echo '<a href="tel:+'.$page->fieldname->unformattedNumberNoExt.'">'.$page->fieldname->formattedNumber.'</a>'; Selectors for searching The component parts can be used in selectors like this: $pages->find("phone.area_code=123"); Field Settings There is a field settings for the width of the inputs in pixels. There is a field settings for the width of the inputs in pixels. You can also choose whether to display the country and extension fields for input. Off by default. There is an additional checkbox that determines whether there is an option to override the default format option on a per entry basis, which will be useful when styling phone numbers from different countries on the one website. Off by default. Custom formatting options On the module's configuration page you can choose from predefined formats, or create custom formats using syntax like this: {+[phoneCountry] }{([phoneAreaCode]) }{[phoneNumber,0,3]-}{[phoneNumber,3,4]}{ x[phoneExtension]} which generates: +1 (123) 456-7890 x123 Each component is surrounded by { } The names of the component parts are surrounded by [ ] Two comma separated numbers after the component name are used to get certain parts of the number using php's substr function, allowing for complete flexibility. Anything outside the [ ] is used directly: +,-,(,),x, spaces, etc - whatever every you want to use. There are lots of complicated rules around numbers changing when dialed from different locations. A simple example is for Australia. When dialing from within Australia, area codes start with a 0, but when dialing from another country, the 0 must be omitted. You can write a simple format to handle this. The following truncates the first number from an Australian two digit area code: {+[phoneCountry] }{([phoneAreaCode,1,1]) }{[phoneNumber,0,4] }{ [phoneNumber,4,4]}{ x[phoneExtension]} which generates: +1 (7) 1234 5678 x123 even though the full "07" is stored in the area code field. Where to get Available from github: https://github.com/adrianbj/FieldtypePhone And the modules directory: http://modules.processwire.com/modules/fieldtype-phone/ To Do Need to increase the number of pre-defined formats. There seem to be so many options and no real standards, so I thought rather than create a huge list of options that no-one will use, I thought I'd wait and get you guys to contribute them as you need them. Either post your formats here, or send me a PR on github and I'll add them. How to install Download and place the module folder named "FieldtypePhone" in: /site/modules/ In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. Now scroll to the FieldtypePhone module and click "Install". The required InputfieldPhone will get installed automatically. Create a new Field with the new "Phone" Fieldtype. Choose a Phone Output Format from the details tab. Acknowledgments This module uses code from Soma's DimensionFieldtype and the core FieldtypeDatetime module - thanks guys for making it so easy.

Hey, The Form API has CSRF protection build in, but if you for some reason don't want to use the API you can however use the CSRF protection. Its very simple but it took some time for me to find out, so i figured i share my findings with the rest. What is CSRF? First you need to create a token and a token name you do that as following: $tokenName = $this->session->CSRF->getTokenName(); $tokenValue = $this->session->CSRF->getTokenValue(); Very simple. Now what you want to do is create a hidden input field like this: $html .= '<input type="hidden" id="_post_token" name="' . $tokenName . '" value="' . $tokenValue . '"/>'; Now this will generate something that will look like this: You are done on the form side. You can now go to the part where you are receiving the post. Then use: $session->CSRF->validate(); This will return true (1) on a valid request and an exception on a bad request. You can test this out to open up your Firebug/Chrome debug console and change the value of the textbox to something else. Basicly what this does is set a session variable with a name (getTokenName) and gives it a hashed value. If a request has a token in it it has to have the same value or it is not send from the correct form. Well I hope I helped someone.

Processwire's performance has always been fantastic for the projects I've used it with - but I'm currently working on a real estate project (converting it to PW) and hitting some performance issues. I have about 800 different fields in PW (crazy, I know) I have a few templates with about 400 fields each (crazy, I know) - all of these fields, with the exception of about 10, are simple text fields. Quite often, pages using these templates have a lot of blank fields. One of the fields is an images field. Several of the MySQL tables I'm pushing over into the PW template/field structure has about 400 columns in them. (Each record is a real estate property listing.) Important note: the site is currently on a shared host, so I'm not completely certain if that is the sole issue for the poor performance or if it is simply the fact that there are hundreds of fields to deal with. Issues I'm facing: Whenever I go to /processwire/setup/field/ (to see the fields), it takes FOREVER to load the page (and sometimes times out). (I know that's a lot of info to load, but what's happening in the background here? Can something be done to make it load faster?) Creating a new page via the API and populating it with data in one shot takes quite a long time. Questions: Can using a VPS single-handedly fix the performance issue? Is there a better way to structure the data rather than having it all in one page/template? (Consider the fact that I have all the data at my disposal when creating a new property record and it all needs to get saved.) Is having that many fields in PW in itself not a good idea? (Meaning, would it be better to leave the data in MySQL - outside of PW - and grab the data using wire('db') and custom SQL statements? I would just hate to resort to creating SQL search queries for all the queries I'd be using. I'd much rather use PW's selectors.)

HallExchange is a classifieds service exclusively for college students. Right now, it is only open to students from my school, but will expand to other college's in the future. What do you think? http://www.hallexchange.com/

my problem was solved only with the abobe code take a look at this snippet at the end of the page, in his mail $header he adds .'Content-Type: text/plain; charset=utf-8'."\r\n"; see the link below http://ncona.com/2011/06/using-utf-8-characters-on-an-e-mail-subject/

hi janlonden i had a same problem once with greek language and i found a solution in stackoverflow. i do not know if this will help you but you can give it a try. so instead of mail($emailTo, $subject, $message, "From: $form[epost]"); try this mail($emailTo, '=?UTF-8?B?'.base64_encode($subject).'?=', $message, "From: $form[epost]");

EDIT: complete file is here ----------------------------------------------------------------------------------------------- Ryan, I cannot create a second PR at GitHub, so I add the rewritten code as zip attachment here. And it is really good that you will understand it in full after merged it. Because, also if I'm not on vacation (lets say 6, 7 months ago) I'm not sure if I will remember right all the things. So, I have added few more comments to it. BTW, these page about gamma errors is awesome. I have done the test with my Photoshop CS6 Extended localized german for nearly 2k € (if not an upgrade) - and it fails completly with 8bit images. I only get the grayish result with some colored blurriness like in the examples of the site. The short story is: try to scale this prepared image at 50% with whatever software you want. How does your result look? Like this one: or like this one: If you want to know why and how, pleas look here: http://www.4p8.com/eric.brasseur/gamma.html#introduction

Wow Ryan - those new multi-value fields sound brilliant - can't wait to see your implementation. I'll have to use them, just to have a reason to send some money your way. You also really got me thinking about the potential of custom fieldtype/input field combinations for an upcoming project which is extremely data heavy. I will still definitely need several custom database tables and SQL queries for the data manipulation side of things. These queries actually take quite some time to run, but only need to be run periodically to generate results. So I am thinking that I will store the manipulated results of these queries in some custom fieldtypes which will dramatically reduce the number of PW fields, yet still allow for API querying of the final results on the front-end. So many cool possibilities

Superexcited about ProFields!

You should be able to use this module from the API side like you've mentioned. The module is built around a jQuery UI plugin called uix.multiselect, so you'll want to make sure that your context includes jQuery UI. Like with all of the selection inputfields, you'll have to add some selectable options: // add some options $test->addOption('a', 'Option A'); $test->addOption('b', 'Option B'); $test->addOption('c', 'Option C'); // now tell it which ones are already selected $test->attr('value', array('a', 'c'));

Ahh, that makes total sense - I am sure it is because all your fields become objects because of the two language versions eg: "body": { "data": "", "data1029": "" }, rather than just simple strings. Not sure how difficult this will be to fix - hopefully simple

@sitnarf - you mean like this? http://processwire.com/talk/topic/704-datatable/?p=40621

As a side note, I just wanted to mention that you wouldn't want to use dirname() in a URL like that, as it's giving you a server path, not a URL. Secondly, if you were using dirname(__FILE__); somewhere else, remember that its output does not include a trailing slash like ProcessWire's paths do. So you'd have to add a trailing slash to it's output.

You can always use a try { ... } catch(Exception $e) { ... } but I think it's probably better to leave that as a fatal condition and stop processing.

I'm not really sure of the source of the issue here, but can answer some things about the original error you received here. Page::statusCorrupted means that some code modified the value of a page field when output formatting was ON. That means that the page is in a state where saving it could cause data corruption (like saving formatted data to the DB). The way to prevent this error is to ensure that output formatting is OFF before you retrieve and populate back any values to the $page that will be saved. You can turn off output formatting via $page->setOutputFormatting(false); or just: $page->of(false); If we look at the code where the error originated, it's a bit unusual because output formatting is being turned off before the save(); I would look in code unrelated to and above your comments code to see if you are setting any field values to the page. Given that the page has statusCorrupted and we can clearly see $page->setOutputFormatting(false); that means that the page had already been corrupted before your comments were even rendered. Meaning, I think there is a good chance this is not related to comments at all. Check what's in your own code (any $page->set(key,value) or $page->field = "value" anywhere?) and if you don't see anything there let us know what 3rd party modules are installed.

I've not attempted to modify the SCSS files or anything like that. The Foundation that comes with this profile is just a stock version of it, directly from their ZIP file. To update it, you simply replace the /site/templates/foundation/ directory with a newer one downloaded from their site.

I just tried to use FieldtypeConcat instead of implementing my modifications and it didn't seem to work. While I was at it, I decided to make these into modules (compatible with PW 2.3.0). Its out on GitHub: https://github.com/Hani79/Processwire_FieldtypePageWithLabels Tested and seems to work just fine. However, I have a question, Ryan. I ended up simply duplicating the InputfieldPage and FieldtypePage modules and made my changes. I did this rather than extending InputfieldPage and FieldtypePage. Was that the right way to do it? I tried to extend FieldtypePage itself, but was unsuccessful. I was getting the following error: Which was referencing this line: class FieldtypePageWithLabels extends FieldtypePage {

OK, I have a new version ready, with a new name: Page Tree Migrator This new version has a new Github page: https://github.com/adrianbj/ProcessPageTreeMigrator It can still handle simple "page list" imports and I have update the format of the countries.json and us-states.json files at: https://github.com/adrianbj/ProcessWirePageLists WARNING: It should still be considered alpha at the moment, so please be careful !! You will now need this new module to be able to import those files. Whats' New Ability to import any page tree with infinite levels of children Templates are now created with all (I think?) settings from the original setup (including Family child and parent templates allowed). Three export options: - Everything, including all data pages - Field, templates, and structural pages - Fields and templates only I am not really happy with the middle one yet (see Road Map for more details), but I think the other two are very useful. Road Map Testing - It has been working great for me so far, but I am sure you guys will find some problems - I know it is far from perfect Code cleanup - at minimum I want to rename some variables etc to be more logical and add some detailed commenting. I am sure someone with more PW experience will see a mess in how I have achieved certain things. I know of a few things already that I want to redo, but for now I just want to get it out for testing Add more options for the "Field, templates, and structural pages" export option. At the moment this exports the templates, fields, and all pages, except for the final child level. My logic was geared towards something like a gallery with this structure: Gallery --Nature ----Image 1 ----Image 2 --People --Animals So, with this export option, you would only export the Gallery parent page, and the category pages (nature, people, animals). The image grandchildren won't be exported so you can use this to start with a clean gallery page tree. However, I think I should add more options that allow the user to select which levels of children to export and even which fields within these pages. That way you could choose to only export the title field for an entire set of pages, leaving the rest of the fields empty. Not sure of the most useful approach here. Any thoughts? Deal with any potential issues that occur when importing over an existing template if existing settings are different. What else do you guys want to see?

@wishbone, live's a risk you should take ! $test0; // = Null $test1 = 16; // = Integer $test2 = 15.5; // = Float $test3 = true; // = Boolean $test4 = "bc"; // = String <- here you can use curly brackets, sometimes you must $test5 = "a{$test4}d"; // $test5 = "abcd"

Ay - I here you there brother. It's a coded jungle out there with brackets, curly brackets, comma's, semi columns, double quotes, single quotes, double points, forward slash, backward slash, arrows, white space, etc. etc. And then all that is going to be mixed with php, api, html, apart from css and js.

I like curly women.

Totally missed those dependent selects on first watch. Amazing stuff, thanks Ryan!

I'm going to ignore the field completely and jump straight to shouting: THANK YOU SO MUCH FOR DEPENDENT SELECTS! This is yet another awesome feature I've been silently wishing for for a while - one select field causing a filter on another (which I'm guessing works also for just two regular select fields and doesn't rely on this fieldtype?). Loving how, logically, when the first select field doesn't have a value the second simply isn't shown. Back to the module - I love that too, but one select filtering another one opens up a new world of possibilities so I'm ecstatic with that by itself

I personally think that the way that the current ProcessWire admin functions is exactly how it should continue to function, I'm not a fan of the always available page tree (or any kinda of extra clutter really), I've rarely had a client I was confident could understand/effectively utilize such a feature anyway. I get fewer calls about "CMS confusion" with processwire than I ever have before with ANY platform (yes, even WordPress). Though developing a new admin theme that may make itself more conducive to the addition of such major features would be great, if doable?(I'm not master programmer so I have no idea) I really think this simplicity is key in a default shipping product. Also making the default theme clean/minimal would also potentially make small visual changes easier for developers. My concerns about the theme don't come from a function stand point as I think some of the ideas floating around in these forums serve more to solve developer issues than client issues, and in the end our primary concern, particularly for the default theme, needs to be client experience. My concern is that honestly I was one of these superficial types that overlooked PW because the admin wasn't "cool" or "slick" enough for my tastes. There was probably a 3-4 month period between when I first discovered PW and watched the intro video to when I ended up back here out of my continued search for a "custom post type/custom content" CMS. This second time I took a peek around in the forums to realize that PW supported admin themes, I was in. Between Futura Remix and at the time a preview post for Ergo I knew I could be happy with the look of PW. But obviously not perfectly happy as I was still motivated to go on to make a few of my own (one particular motivator was the use of Jquery ui and its awful awful icons). And frankly in general jqueryui is a bit ugly and very dated looking (though I can understand the concern of moving away from it, seeing as how much code would need to be rewritten). The point before being that there is a very real risk of loosing out on new users because of this (just look at the CMS "Craft" which recently got tons of attention in a bunch of webdev blogs and yet has no single feature that processwire doesn't except it has a gorgeous admin interface, AND you have to PAY for almost all the other good features!). I think one thing that happens is people can't so quickly understand how amazing, flexible, straightforward, powerful and generally beneficial the PW API is, but what they can understand immediately, is whether or not the CMS admin panel is cool, clean, slick, simple, sexy.... whatever. And I think PW falls short here, its not terrible, but its nothing exciting. There are certainly plenty of CMS' to draw inspiration from though: Symphony CMS, Kirby admin panel plugin, Craft, Statamic, Anchor CMS... I'm sure there are more. I think the most effective place to put effort for now it a simplified cleaner rewrite that better supports 3rd party admin themes, no more specificity battles (there should be no need for the use of "!important" in the default theme, or at least very little). This combined with the ability to have "Admin Theme settings" and a per user admin theme selection could really fix most of the concerns floating around (at least I think so...). I really think something that takes the colors from the new processwire.com and a bit of inspiration maybe from others could really nail it. Oh and, I really think switching to an icon font would be smart..... and ditching jqueryui.... I'll stop here... phew.

Very impressive work. Functions as how it should.

Great job on this one! Impressed also on the screencast, very nice to listen to you. I'm just curious for now about caching html. Why didn't you use the MarkupCache feature of PW? Of course your technic using a text field is also nice.

This is still not really finished. It definitely works and has been tested on a couple of different sites for several months now, but I think it still needs some refining before being ready for prime time. It is now on GitHub: https://github.com/adrianbj/ProcessPDFImageCreator Will wait for module directory submission until I get time to make some refinements though.

@Pete - i've been using Diogo's custom admin pages to handle situations with a lot of data that I want to put into a custom table, using dataTables.js, so since this is the results of a selector, i would guess that you could show the repeater data in something like this...

It just occurred to me that it would be amazing to be able to use a datatable for repeaters. I know it's certainly by no means a simple request, but it would definitely be neat and in some cases preferable when handling lots of repeaters or working with certain data types. Just a thought.

Just as Soma mentioned, use the FieldSet field type to create your columns, and then set their width so they float next to each other. In my case I made 3 FieldSet columns. (column_1, column_2, column_3) — although I only used 2 columns in the screenshot above. I didn't want to change how the admin looked anywhere other than within these columns, so the only thing I changed about the default theme was a few lines of CSS that are specific to these columns. You can grab the CSS here

Thanks Ryan, I managed to sort this out by sticking with the repeater option, but instead of using a repeater as a singular method for date entry, I used it for "additional dates". That way, the majority of events are entered with a typical start/end date, but events with more complicated schedules can use the repeater. I set the ready fields to 2, that seems like a good place to start. I think this will be less confusing to the people entering events — at least I hope. See attached. (note: tweaked the admin via FieldSet to create 2 columns for calendar entry, I love how flexible PW is.)

I don't think this is something that can be done in a straightforward manner unless you modify and replace InputfieldPage.module, where this label is assigned. However, it seems like a good idea and we can look at making this an option in the core module for the future.