adrian

I haven't ever experienced this error, so maybe there is something else involved, but you have a semi colon at the start of the line which means it is commented out and not used. Try removing the semi colon and also be sure to restart apache to have the changes take effect.

I think you're referring to select options (ASM etc) and the page fieldtype and how best to set up and where to store the page tree that contains the options for selecting from? alevine - is that the gist of the first part of your question?

Yeah, I know. I guess the title of post isn't really accurate as at the time I didn't realize that removing it completely provides different behavior to having it unchecked. I guess I think the page-edit should not be affected by page-publish. Maybe there needs to be a page-edit-published as well to provide the scenario I am talking about. So you could check page-edit, page-edit-published and uncheck page-publish. Might be a better way to achieve this, but you get the idea.

Hey Ryan, that is exactly what it is doing for me right now too. I can only assume that right now I need more sleep, but I'll keep an eye on it.

Hey Soma - that is the permission we are talking about. Once it is set up, but unchecked, it overrides the ability of a user with page-edit to edit a page that is already published. Hence there doesn't seem to be a way to prevent a user from publishing a post, while still giving them the ability to edit a published post, which seems like a valuable scenario to me.

That is actually the permission I am referring to above as "Publish/Unpublish" - that is the title it is set to. I didn't realize that removing the permission would do what pogidude describes. There still doesn't seem to be a way to set someone to be able to author and edit published posts, but not actually do the publishing - am I missing an option somewhere?

At this point I haven't really thought about the workflow, but I think there might be some room for improvement there. Initially, I am just wondering if it makes sense that a user who has editing rights should be blocked from editing a page, just because it is already published - maybe it is more of a terminology issue for me at the moment.

I wonder if this is completely logical. I can imagine a scenario where I have a user that I don't want to have permission to publish a page, but I am happy for them to edit a page once it has been published. Not really a trust issue, but rather want to ensure they can't accidentally publish a draft until it is ready to be public. This is currently a theoretical scenario for me so I haven't gone looking for solutions, but just want to raise the issue and see what the consensus is.

I have been using dlvr.it - I found it was more reliable handling at ensuring the images made it through to FB. I had some troubles with RSS Grafitti. There are lots of other services out there for RSS to FB/Twitter, which seems like the easiest approach.

I think this might be by design, but when I go to link to a file from a RTE field, it doesn't show files unless they are in fields named "images" or "files". Shouldn't it find all fields that have field or image as the field type?

I think the problem is the spaces here: eventStartDate >= $today Try: eventStartDate>=$today Also, in case you don't know about it already, check out this module for testing selectors: http://modules.processwire.com/modules/process-selector-test/

Perfect solution. For those who find this and want to deal with it. In site/templates-admin/default.php, modify this line to read: $last_modified = $pages->find('limit=10, sort=-modified, start=0');

Just discovered a weird bug - If you have more than one page of admin users and you are viewing any page but the first, the latest updates section in the sidebar also shows results from page x of its results. Not sure if this is a general PW bug or something specific to this theme. How does PW generally handle pagination when there are two things on a page that both allow pagination? I haven't come across this scenario before. Anyone?

I wonder if you don't have the Textarea (Multi-language) module installed. It is a core module, but not installed by default. The other thing to try when migrating to new servers is to do a test install (in addition to copying the folders across) so the installer requirement checks are run.

Thanks Ryan, but the 404 page is/was not viewable by the user, so I don't see how they could have changed it. The page they edited the name of also disappeared from the page tree and all the content was actually in the page with ID of 27, including all the uploaded images - which actually even ended up in assets/files/27. I am baffled how that could happen, but it did

Awesome diogo - thanks for the quick fix - sorry i didn't think to look there last night - was too late

Just used this for the first time - so easy! I am using 1.04 with the latest dev (as of today) Thought everything was working great, but then when I went to test to see if general admin users could see it, I discovered that they could see the new page just below "Access", but then when I clicked on it, I get a "You don't have permission" error. I have looked through all the permission options I can think of and can't seem to get it working. Any thoughts please?

Ok, here is a very weird one. Just had an admin user change the name of a page (direct child of Home) to "Contribute" from something else. Not sure that the new name is relevant. Somehow this page then took an ID of 27 which is the ID of the 404 Page Not Found page. It was set to hidden and the template was changed to basic-page. The page can't be viewed by non-superusers. As a superuser, I can't delete it, or even move it's position in the page tree (it moves, but the change doesn't stick). The person thinks they were using the main admin, but I do have the Admin Bar installed, so I wonder if this might be involved. Anyone have any ideas on this? By the way - I managed to clean things up via PHPMyAdmin to change the ID of the page and everything is working fine again, but it does seem like there might be a bug somewhere.

Hi Mike, Apeisa has this module: http://modules.processwire.com/modules/fieldtype-poll/ I haven't used that, but I have used the following code from Ryan successfully for a couple of polls and it works great: http://processwire.com/talk/topic/218-simple-poll/?p=1456 Hope that helps.

As far as I know, all it does is add the "_END" to the name of the field, which is what is required to define the end of a fieldset. Although I did try manually adding it and it didn't work, but maybe I had something else messed up at the time.

Soma - thanks muchly for the point in the right direction - it was the FieldtypeFieldsetOpen::fieldsetCloseIdentifier; that I was missing. Everything seems to be working great now!

I can create the FieldtypeFieldsetOpen no problem, but can't figure out how to create the FieldtypeFieldsetClose. It doesn't seem to be automatic like it is via the admin and I can't seem to create it manually either. I imagine automatic wouldn't work because it wouldn't know what fields belong inside the set. I have created the required fieldset using InputfieldFieldset and the layout looks ok until I want a second fieldset in the same template - then the need for the Close / _END field becomes important. Anyone have any ideas? PS I have been using this example as a starting point for generating the fieldsets: http://processwire.com/talk/topic/1196-api-show-field-label/?p=10691 but without defining a FieldtypeFieldsetOpen it doesn't really seem to do what I want in that nothing gets grouped in the admin.

I actually don't know what you mean by the "reply" or "another reply" links - I only have the submit button. Can you attach a screenshot of the links you are clicking on and then the url of the page that produces the 404 error, as well as describing the page tree that you see when you browse the forum posts in the admin. I am sure we can figure it out from there.

Did you create all the required .php template files, as per these instructions? http://processwire.com/talk/topic/572-release-discussions/ I have used this in a couple of sites without problems, so as horst says, it should be an easy fix to get this working. Whether it suits your needs is another story - it is a very basic (but effective) forum. Actual proper user integration with other forum software will be much more complicated. You could potentially install some and style to match your PW site though with less effort. Here is a recent thread that might want to start following as Pete is looking to possibly build some forum integration: http://processwire.com/talk/topic/3536-forum-integration-module/

The search.php file that comes with the default profile includes the following line: $matches = $pages->find("title|body|sidebar~=$q, limit=50"); That error suggests to me that you don't have the sidebar field in any of your templates, so you should remove "|sidebar" from the search.php file and I think you should be fine.