apeisa

Thanks slkwrm! I would have recorded a screencast, but I am hitting bandwith limit on screencast.com.. should probably start using YouTube. This will definitely take few more hours to polish (even if I don't add any new features), but I was very surprised how little time this took. I was prepared for few days of coding. But the fact that I use pages for all the admin stuff (edit, remove) makes huge savings though. But I am planning to add inline edit functionality for admins, so that you don't have to go admin every time you need to edit or remove posts.

Updated the file with few fixes (admin rename -proof method to find users page and using prepend rather than append on renderTopic method).

I know, that is why I asked for help for this I updated that already on my local copy, but need re-install my module to make sure it works (that I didn't make a typo etc). EDIT: And it works, I update the module here on forums, will put it to GitHub soon.

It is! And welcome to the forums koorb

Thanks Ryan! I like the latter way a lot. Will add this soon, just released this module: http://processwire.com/talk/index.php/topic,626.msg4691.html I used this now: wire('pages')->get('/processwire/access/users/')->id;

Very simple discussion board using pw pages as topics and replies. It means that you can use the great API with your discussions also. This is VERY tiny in features, but I am open to suggestions. I want to keep this small, since there are plenty of great php based forum software around, and this tries to nail much simpler needs. What this does currently is: Multiple forums on site Multiple topics on forum Only logged in users are allowed to post Admin stuff is handled true pw-admin (everything are just pages) Replies and topics are tied to user accounts Current shortcomings: You cannot change markup easily You cannot change text / date formats etc (waiting for PW 2.2 for this) How to install Make sure you run the very latest version of ProcessWire 2.1, at least this commit or newer. Download the file from github and copy it to /site/modules/Discussions.module Go to admin -> modules and "check for new modules". After that click Install on "Discussions" It creates 3 fields and 3 templates for you. But it doesn't create 2 required template files - you need to get your hands dirty. Create two new template files: discussions-forum.php and discussions-topic.php Edit your new templates and add this line to both of those: echo $modules->get("Discussions")->render(); Create a new page and give it template: discussions-forum You probably want to add Markdown Extra textformatter to your discussions_message field. (Ryan, how to do this from install script?) That is pretty much it. It will look ugly as hell, so you really want to add & edit some css (very basic starting point provided below) /* DISCUSSIONS -basic styling */ #discussions { position: relative; width:100%; overflow: hidden; } .discussions-reply, .discussions-form { padding: 20px 0; border-bottom: 1px solid #ddd; clear: both; overflow: hidden; } .discussions-form { border: none; } .discussions-information { float: left; width: 20%; overflow: hidden; } .discussions-author { font-weight: bold; display: block; } discussions-datetime { font-size: 0.9em; color: #666; margin-bottom: 1.5em; } .discussions-message { border-left: 1px solid #eee; padding-left: 3%; margin-left: 2%; width: 74%; float: left; } .discussions-form label { display: block; } .discussions-form textarea { width: 90%; } #discussions .discussions-message p, #discussions .discussions-message table, #discussions .discussions-message ul, #discussions .discussions-message ol { margin-top: 0 !important; } /* Pagination */ .MarkupPagerNav { margin: 1em 0; font-family: Arial, sans-serif; overflow: hidden; } .MarkupPagerNav li { display: inline; list-style: none !important; margin: 0 !important; } .MarkupPagerNav li a, .MarkupPagerNav li.MarkupPagerNavSeparator { display: block; float: left !important; padding: 2px 9px; color: #fff !important; background: #2f4248; margin-right: 3px; font-size: 10px; font-weight: bold; text-transform: uppercase; } .MarkupPagerNav li.MarkupPagerNavOn a, .MarkupPagerNav li a:hover { color: #fff; background: #db1174; text-decoration: none; } .MarkupPagerNav li.MarkupPagerNavSeparator { display: inline; color: #777; background: #d2e4ea; padding-left: 3px; padding-right: 3px; } This was very fast to code (I estimate 6 hours, certainly under 8 hours). I consider this version as a alpha, not tested that much (well, it works on my computer ) and I do wanna add some features and get feedback (how it works, any security issues etc). All feedback is welcome.

Is there simple and 100% sure way to get /access/users/ page id? Need to set that as a parent_id for one of my fields (Page).

Yep, that is true. It's not that big job, probably just 15 mins, but every time there is "boring" stuff ahead, I start to look alternatives Thanks for the code, will definitely use it as a reference!

Ryan: this new hook works perfectly! Other thing: only thing keeping me from releasing this little "beauty" is that to get to coding quickly I build fields (4) and templates (3) by hand. I started to code those through API, but soon realized that it might be much faster to do some kind of export/import here... Fields are pretty easy, since each of them have their own tables and no required relations to other tables, right? Templates aren't too hard either. I have few relations there (template ID:s are different on different sites): {"childTemplates":[45],"parentTemplates":[43],"allowPageNum":1,"slashUrls":1} But those parts I could easily add after the import. Is there any downsides on my thinking? Should I do these through API or just DB import? EDIT: Ok, I think I create templates through API, since there is fieldgroups_id relation also. Field export/import seems to be very simple. EDIT2: Started doing fields import and at some point noticed that each fields_table is almost identical, after that I noticed that there is actually fields table also, which actually keeps all the settings etc. So it seems that this might be easiest to just build fields & templates through API. It will be great stuff when we got the templates export / import stuff ready - it will make building & sharing modules also faster.

Maybe just turn Pub more into web dev: I think we have enough boards already That parser looks awesome, need to find a project where to use it

It seems that the last one is just perfect. Will try this soon.

Ok. I actually get something released soon (this will be open source module), just need to polish a little bit and add install() and uninstall functions. Then I should have pretty stable and well working version ready.

I used this one: $this->addHookBefore('Page::render', $this, "processInput"); How much there is overhead using autoload modules? I am using that hook to process form inputs and only want to do those on certain templates - so most of the time processInput just returns false. I want to use autoload here, since it is very important to do valid redirect here after post (so no "re-posts" are possible). EDIT: fixed addHookAfter to addHookBefore

Ryan, when we build the adminbar module you wrote in the init() comments this: * The init method of a module is called right after ProcessWire is bootstrapped, when all * API vars are ready. Whereas the __construct() is called DURING bootstrap, so the init() * method is a better place to attach hooks to API vars. But it seems that I cannot access $this->page in module's init() method? Also wire('page') returns null. This is just a confirmation - I know how I can go ahead, but wanted to ask this anyway.

Yes, you should downgrade to 2.0 and it should work just by putting old /wire/ and .htaccess and index.php back. And after that you should follow upgrade instructions from here: http://processwire.com/talk/index.php/topic,583.0.html (2.0 => 2.1 is actually export & import).

I spend few moments to visit all these sites and read these reviews and comments... Gotta love what you guys have written! Actually to take this to broader scope - I don't know even a single php developer who has given processwire a few moments and come back with usual "nah, I didn't like it" comment. Everyone has liked it a lot, and there are some very seasoned php-developers and also pure designers too in that group. That is very impressive. And I didn't even mention the clients, who seems to love well build pw sites...

I also like this approach very much. Actually I had the same idea in January (last paragraph), but didn't give that thought too much thoughts back then. I think that in symphony cms there is good implementation if this method. Other scenarios where this approach would shine is ie. tags. You could keep tags as their own pages, but could add new pages when adding new blog posts. Also - you could add architects while editing your skyscraper etc.

There is filter options above template list. Choose system templates and you are good to go.

It was quick one: git log --grep='icon' --pretty=oneline

Gear icon is PW2.1 only (I assume) and came in July: https://github.com/ryancramerdesign/P21/commit/c99a

Thanks Ryan - I don't know how I missed that. This helps a lot!

Hi sa_designer and welcome to the forums! Images (and files) are little bit different from text-based fields. Here is topic which helps you forward: http://processwire.com/talk/index.php/topic,16.0.html and even more information from here: http://processwire.com/api/fieldtypes/images/ Also one way to show images are when using TinyMCE field - just click image field and choose the image. But best use is usually in templates.

Interesting to know that you have had exact the opposite experiences with this. Document management system that we use internally has this kind of lock in (only person who edits or admin can release files ) and that is major pain in the ass. Gotta admit that it is different kind of beast since it integrates into the operating system, and not web service used through browser. What I meant earlier is not that editing is managed for each page separately, but that if each who can have edit access can also release pages (that are locked for someone else). It should be enough in almost every situation. It must be then well known decision - because you need to make action before you can start editing. In other case it might be open computer somewhere (home, work) and person some other place and unable to release it (or just that no one cannot contact that person). That is what happens for us every now and then with our documents.. Locked for person X who doesn't answer his/her phone... I think that risk is even worse than overwritten content. Think of broken link on promoted item on front page, which no one cannot edit etc... I think good idea would be show the exact time when person who has been editing the file has been active. Something like this came into my mind: "This page is under editing by Antti Peisa (email.address@example,com) and locked because of that. Editing has started 3 hours ago (18:45) and Antti was last active 2 hours ago. You can release this page if you need to start editing, but you should contact Antti to make sure that you won't edit same page at the same time." Of course I don't mind having settings and different use cases, but as always I support for simplicity and finding the best way. Too many settings lead to bloat. But after reading Soma's post I think my view might be little bit limited here. Also clients I tend to work are pretty similar organizations - although in many different sizes.

I slightly disagree. One way (=best) how it works and one setting: on / off This is feature that is not relevant for all sites (I might say that probably only for 20% of sites or something). Many many sites have only one or few editors and they edit certain areas of sites each. So many times it causes more trouble than it solves. Although in some cases and organisations this can be very beneficial. But I think it should always be something that everyone with edit access can open.

You will. PW still has few shortcomings in features compared to more mature products, but almost everything that has been implemented are very well thought out and solid work. And all the credits to ryan, we others mostly just hang out here