apeisa

Other note: I am all in for ditching support for IE8. I know it is currently most popular IE version, but it is behind IE9 for miles. As we all know there are few free alternatives (Chrome, Opera, Firefox, Safari) that all do better job than IE. I rather lose few sales than try to innovate with new features and fight with IE8 problems.

Just tested this with IE9 and deleting images work fine. But if I use the upper save button, then it doesn't remove the images (same bug that you reported earlier).

Nico - good suggestion and this is definitely coming. We just had quick talk about this on Twitter. I hope that this is something that we can do at the same time with upcoming processwire.com redesign.

Probably not worth if it takes more than few hours, but if it comes easily then go for it.

Yep, loads fine now.

Amazing stuff Soma! Will test this sooner than later. Seems like a great implementation.

Didn't go to flags yet, but pushed this to GitHub with bunch of fixes (stuff we talked about earlier). Also updated the stylesheets in first post. It is starting to take a shape nicely. I need to think about flags & uninstalling a little bit more. I also want this to be easily extendable if someone has bigger needs, so then all the extra magic or hiding will be just annoying.

In ProcessWire almost everything are pages. Currently all "normal pages", users, roles, permissions, admin pages etc are pages. To take it further, if you build tagging, each of your tag would probably be a "page". Page doesn't have to be something that is accessible from certain url (although it gets a unique url which is one way to identify and give meaning for that certain page) and something that is "meaningful" on his own. Page = node = item = row etc.. So if your site would be just clean PW-implementation then offices would be pages and there would be relation between buildings and offices. And if office can be only in one building, then you probably would just add them as child pages (relation comes there from page hierarchy). But if same office can be in multiple buildings, then you would use special "page"-field, which allows you to have relations between different pages. So you could choose on per building basis on what offices there are.

Hi Steve and welcome to the forums. For me it seems that your application would fit ProcessWire nicely. Although with this information it is hard to say if it would be wise to implement data syncing between offices database or just read that database directly or through some kind of API (and I think that this is something you need to decide however you will build your application). PW doesn't get into your way at all when you need to do some "real coding". In Soma's answer he talks about the way where you do sync the data, but you could also just save ID values from offices DB and query the data from there. Yes, PW got that. You can define per template basis if you want to allow urlSegments. If you do allow, then you get those as a parameters in your template: http://processwire.com/api/variables/input/ (Retrieving URL segments via $input->urlSegment(n)).

Very nice and clean sites both of them. Only minor issue I noticed was that navigation styling on dgcreative.net site could be better. I tried many times clicking on words "DESIGN" and "PORTFOLIO". It is little bit confusing to have them with exact same style than you have "ABOUT US" and "CONTACT" which are clickable links. Other than that - I liked both sites! They feel just a little bit slow from here (Finland), but sites seems to be well coded and light - so that seems to be hosting / network issue. It sometimes take over 2 seconds to load 160kb image.

Great stuff! Can't wait to see this finished.

Great answer Ryan! Thank you. For bigger changes it's same script and you have new copy of the exact same site where you can build and test freely (well, on same vps, but different db and folders - no any connections between the sites). Just copy the site you need to work into some temp domain (ie. ver2.example.com) and start building: ./new_site.sh ver2.example.com www.example.com Wire is already symlinked. Although I might use dev side to test if site runs later version of pw without any problems. Only for minor and non DB upgrades of wire of course. I'm not sure yet how many pw versions I keep on server, currently I keep two: pw21stable and pw21head. We will have good testing on before putting live sites here (probably goes to next year anyway) to see how sites behave. But the stuff where we use this dev environment is mainly templates, css and js. I don't believe doing any module development or anything like that on this setup - at least not with live sites. So "dev environment" is probably wrong term for this. Also - I will have oneliner scripts to check status (are dev and live identical), update (files from dev => live) and to reset (from live => dev).

Thanks for this. I will take a look at the late evening or tomorrow.

Separate release would be nice. That way everyone could start translating the admin already.

Thanks for the info. Files won't be problem, since dev version have /assets/files/ folder as symlink, so dev site uses all the same files than live. What kind of problems there could be with module installs etc? I might even go with symlink route there as well if needed. In your setup, you then build the db changes again when deploying? Or do somekind of partial import there?

We don't. Dev and live uses same database. After the launch we'll do our dev work on live database and working with actual content. It has never been a big problem (quite a opposite, it has many benefits), but it might cause now more issues, since pw manipulates databases much more than our own cms. But pw also fails silently (when I add new fields to templates, it doesn't matter at all if client "pre-populates" those before I have updated the template files). I am pretty sure that we won't go into db syncing at all.

Doing some refactoring here with this module, and while building uninstall method I started to thinking about fields. Currently we have system and permanent fields. Should we have module fields also? They could be fields that cannot be added (at least too easily) to other templates and/or are hidden from fields list by default? Not given this much thinking, since it's getting late. I wanted to build easy and quick way to uninstall this (just check if there isn't any pages using discussions-* templates, then remove all templates, fieldgroups & fields that module have created). I achieved this already, but realized that (at least in my current method) fails if site builder have used discussions_* fields in some other templates also.

Currently only way is to remove stuff (through API or manually through admin). Pages first, then templates and finally fields. After that cleaning you could create blank site profile (and maybe share with others?) with Profile Exporter: http://processwire.com/talk/index.php/topic,583.0.html After that you can use your blank state profile to create new projects. Edit: There was also earlier discussion about same subject: http://processwire.com/talk/index.php/topic,279.0.html

Yesterday we worked on our server and deploy stuff. With one script we can create new site (from our demo profile or from any of our sites) with dev version also: ./new_site.sh www.example.com [www.copy-from-any-site.com] that gives us: www.example.com.pwire.fi (live) www.example.com.pwire.fi:8080 (dev - will probably add some access restrictions here) and after www.example.com resolves to our IP, then it would serve live site from there. This will export & import database, copy files over to two places (dev & live folders), do some symlinking (assets files, wire), handle folder permissions etc. It takes two seconds to start building new site from any "profile" we want. I can share that script if anyone is interested here (after I have cleaned it a little bit)? To make those domains work out of the box we added some Apache configuration so that we don't have to configure every vhost manually (but we can if we need some expections). We used Apache mod_vhost_alias to keep things simple: http://httpd.apache.org/docs/2.0/vhosts/mass.html | http://httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html Only thing that caused little problems here was that .htaccess was not working. After little googling we found solution: http://blog.justin.kelly.org.au/htaccess-and-apache-virtualdocumentroot Not sure how this should be handled in PW default .htaccess file. Probably just comment for this option like it seems they have in Drupal: http://drupal.org/node/118569

And it seems that Ryan is already doing es-ES

Yep, that looks even better. Will switch again. Kids went just bed and wife is doing some knitting so it means some evening hacking here

Ryan, thanks for your feedback! I really appreciate it. You are right about the issues with that solution using get params in redirect. Gotta say that it was last "feature" I build and don't know how I ended up using that solution. Will use $session there. I have copied code snippets from various sources, so that explains the differences in $page. Will probably settle with wire('page') - don't know why but I like it Thanks for the textformatter tip also - I actually use MarkdownExtra on my test installation and I am planning to implement markItUp editor into discussions also (maybe with preview).

Great stuff guys. fi-FI coming from here!

What I mean here, is that you can get pretty cool stuff through API easily. All topics started by current user: $pages->find("template=discussions-topic, discussions_author=$user"); 10 latest posts from all forums: $pages->find("template=discussions-reply|discussions-topic, sort=-created, limit=10"); etc...

Thanks! Nope, you don't need discussions-reply template. Based on your screenshot I think you have echo $modules->get("Discussions")->renderForum() in both of your templates. In discussions-topic template you need to have: echo $modules->get("Discussions")->renderTopic(). Now that I wrote that it doesn't make any sense to have different methods for those, I updated it to support just render() on both of those templates (old way works too). PS: I wanted to keep discussions-reply as their own template mainly for nice template-based selectors. Also to make sure that replies cannot have any children.