ryan

_('text') is for gettext, but ProcessWire doesn't use gettext. I think that _() was actually meant to be a __('text') or a $this->_('text') ? Those are the ProcessWire translation functions, among others.

I'm not at my desktop computer, but think it is MySQL 5.5.25 (under MAMP) that I'm running. But you are right that assigning the default value to the text field in this module's schema wasn't right, so I pushed a fix for it a couple days ago.

I definitely did try it with a concat field--I still have test_concat_renamed sitting in my fields list. But I see what you are getting at: since this field has no tables, why is it apparently trying to rename tables in your installation? That's a mystery. I will take a closer look and see what I can find.

Also, don't forget about the "hidden" checkbox on every page's "settings" menu. That by itself would enable you to hide items from the Foundation menu. This is the method that is used natively in the profile to hide things like the search page from appearing in the menu.

It's best to have your translators do their job of translating static text once you've finished your development work. Either that, or like Antti said, use multi-language fields for stuff that you think may change regularly.

$pages->get() implies an "include=all". You'd want to retrieve your pages with a function that filters things. Try replacing your get() with a find()->first(); and I think that'll give you the results you want. $check_field_dupe = $pages->find( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" ); if(count($check_field_dupe)) { // you found a duplicate that's not in the trash } Or you could continue to use get(), but check if it's in the trash after retrieving it: $check_field_dupe = $pages->get( "id!=$current_page_id, $field_name=$field_value" ); if($check_field_dupe->id && !$check_field_dupe->isTrash()) { // you found a duplicate that's not in the trash }

I'm with kongondo, in that I'm confused and not sure I understand exactly what you are talking about. But I'll respond to the nuggets that I did understand. Page status (hidden, locked, unpublished) does not inherit through the tree at all. A status on one page applies to that page only, and says nothing about it's children, etc. That behavior is intentional and will not change. Your site will only display information that you specifically and intentionally output in your template files. If it is for something that you don't want to display, then it can be as simple as not having a template file at all for pages using a given template. If it's information that you only want to show to some users (like authenticated users with role "members", for instance), then you would perform a check before displaying your confidential information: if($user->hasRole('members')) { echo "<p>Launch codes: {$page->launch_codes}</p>"; } else { echo "<p>Sorry, you do not have access to play this game.</p>"; }

Adrian, see this post, which covers how to add your own workflow and/or modify the default behaviors when it comes to dealing with edit and publish permissions: http://processwire.com/talk/topic/3987-cmscritic-development-case-study/?p=40168

I can't duplicate that one. Though it actually looks like a MySQL internal error of some sort, as it's referring to field_query_pages.frm, which is a MySQL format file, not a ProcessWire one. You might want to run a table repair and try again.

Sometimes when I say text I actually mean varchar (since it is also a type of text field). But in this case, I think I must have just forgotten when writing the schema. My version of mysql (and apparently most people's) doesn't complain about a default value in a "text" field, for whatever reason. But I will correct this, as it's sure to come up again.

Once 2.4 is ready and LanguageSupportPageNames is labeled as stable (it may be there already), I'm going to revisit the whole Multi-language documentation section, as LanguageSupportPageNames does change a lot with recommended approaches. I also just [last week] launched an update to http://www.tripsite.com that uses LanguageSupportPageNames, over thousands of pages and 5 languages. Previously it was using the multi-tree approach. It vastly simplified the underlying code of the site, and their editors are so much happier with this setup. The URLs are still mostly English (reflecting the previous names), but at least now it's up to them to decide what the URLs should be in each language. The PagePathHistory module is installed, so that whenever they change a page name, the old URLs will continue working. For instance: English: http://www.tripsite.com/bike/tours/around-venice/ Dutch: http://www.tripsite.com/nl/fiets/tours/rondje-venetie/ Dutch (old URL): http://www.tripsite.com/nl/bike/tours/around-venice/ Now making multi-language sites is so much more fun... I just wish I had more projects that needed it like this one! Hopefully the next major upgrade to this site will be to go responsive.

The exception is coming from Yii rather than ProcessWire, so it's probably a question we can't answer here (unless someone here is an experienced Yii user). But it looks to me like Yii has a controller that is monitoring the request URI "/blast/" and trying to run a Blast::index() method or something like that. Basically, it looks like Yii's version of a 404. You probably need to somehow turn of its URL-to-function mapping, or tell it not to handle the request.

This hasn't been asked, but wanted to cover how the permissions and publish workflow work on the site. It has a very simple, though nice setup, where authors can submit new posts but can't edit already published posts, nor can they edit unpublished posts by other authors. It enables Mike to have full control over any content that gets published on the site, while still allowing easy submission and edits for the authors. Post workflow All of the authors have a role called "author" with page-edit permission. On the "post" template, the boxes for "edit" and "create" are checked for this "author" role. This site also makes use of the page-publish permission, which is an optional one in ProcessWire that you can add just by creating a new permission and naming it "page-publish". Once present, it modifies the behavior of the usual page-edit permission, so that one must also have page-publish in order to publish pages or edit already published pages. The "author" role does not have page-publish permission. As a result, authors on the site can submit posts but can't publish them. Nor can they edit already published posts. In this manner, Mike has final say on anything that gets posted to the site. Post ownership The default behavior in ProcessWire is that the Role settings control all access... meaning all users with role "author" would be able to do the same things, on the same pages. In this case, we don't want one author to be able to edit an unpublished/pending post created by another author. This was easily accomplished by adding a hook to /site/templates/admin.php: /** * Prevent users from being able to edit pages created by other users of the same role * * This basically enforces an 'owner' for pages * */ wire()->addHookAfter('Page::editable', function($event) { if(!$event->return) return; // already determined user has no access if(wire('user')->isSuperuser()) return; // superuser always allowed $page = $event->object; // if user that created the page is not the current user, don't give them access if($page->createdUser->id != wire('user')->id) $event->return = false; }); Planned workflow improvements Currently an author has to let Mike know "hey my article is ready to be published, can you take a look?". This is done by email, I'm assuming. An addition I'd like to make is to add a Page reference field called "publish_status" where the author can select from: DRAFT: This is a work in progress (default) PUBLISH: Ready for review and publishing CHANGE: Changes requested - see editor notes DELETE: Request deletion Beyond that, there is also an "editor_notes" text field that only appears in the admin. It's a place where Mike and the author can communicate, if necessary, about the publish status. This editor_notes field doesn't appear on the front-end of the site. All this can be done in ProcessWire just by creating a new field and adding these as selectable page references. That's easy enough, but I want to make it so that it notifies both Mike (the reviewer) and the author by email, every time there is a change in publish status or to the editor_notes. This will be done via another hook in the /site/templates/admin.php: wire()->addHookAfter('Page::saveReady', function($event) { // get the page about to be saved $page = $event->arguments(0); // if this isn't a post, don't continue if($page->template != 'post' || !$page->id) return; // if this post wasn't made by an "author" don't continue if(!$page->createdUser->hasRole('author')) return; $subject = ''; $message = ''; if($page->isChanged('publish_status') || $page->isChanged('editor_notes')) { // the publish status or editor notes have changed $subject = "CMSCritic post publish status"; $notes = $page->isChanged('editor_notes') ? "Notes: $page->editor_notes" : ""; $message = " Title: $page->title\n URL: $page->httpUrl\n Status: {$page->publish_status->title}\n $notes "; } else if($page->isChanged('status') && !$page->is(Page::statusUnpublished)) { // page was just published $subject = "CMSCritic post published"; $message = "The post $page->httpUrl has been published!"; } if($message) { $reviewer = wire('users')->get('mike'); $author = $page->createdUser; mail("$reviewer->email, $author->email", $subject, $message); $this->message("Email sent: $subject"); } }); Mike, if you are reading this, does this sound useful to you?

Just pushed some updates (dev) to the output of "who can access this page" on the PageEdit screen. Not sure I've got it perfect yet, but found a couple issues there related to what you mentioned and fixed them.

I can't seem to duplicate this one. I give a role page-edit permission, go edit a template, on the access tab check all the boxes for that role and save. Then I go back and edit the role and remove edit permission. When I go back to the template access tab, no boxes are checked except for 'view'. So it looks like what I thought was a problem with cached permissions there isn't actually an issue. But I'm guessing I'm going about the wrong way in trying to duplicate it? Please let me know what steps to take and I'll try again.

Once a system has a page-publish permission, it changes the behavior of page-edit as well. From that point forward, a user with page-edit permission must also have page-publish permission in order to edit a published page. The "who can access this page?" screen is telling you as much as it can about individual roles, but it's not telling you anything about combinations of roles. If a page is published, and there is a role that has page-edit, but not page-publish, then it's going to say it's not editable by that role. And that's true, because if you take that role by itself, the page isn't editable. Likewise, if you've got a role with page-publish, but not page-edit, a user with that role by itself can't edit anything. So this information section can't tell you anything about what might be the results of combining roles. Since that is determined at runtime, specific to a user, the only way you can tell is to try it with an actual user. Before I experiment too much here, I should check if you are testing by logging in as the user, or just by looking at what this info screen says? Stacked permissions should still work for the actual user at runtime. Though let me know if you find they aren't? These settings are cached with the template. So it may say one thing here based on that cached state, but again the runtime result of the actual permissions for a user should be consistent with the user's actual permissions. Let me know if you find it is not, as that would be a bug. I agree this must look confusing. Those checkboxes are getting populated with the cached value from the template. It sounds like what I need to do here is prevent "disabled" attribute checkboxes from having a checked value.

That's the intention: to limit voting to people that are qualified to answer. People that know and are enthusiastic about a product take pride in being able to answer questions like this. I'm thinking that most in our community would be very enthusiastic about answering these questions, and I'm guessing the same goes for other products that people are enthusiastic about. On the other hand, my Mom's mothers club, Soma's high school buddies, Diogo's cousins and Antti's neighbors that arrive there from Facebook with the best of intentions to support ProcessWire (even if they don't know what it is), will get scared off, or at least answer honestly, because they don't understand the questions. IMO, that's a good thing that encourages quality over quantity (with apologies to my mom, Soma, Diogo and Antti's Facebook friends and of course the mothers club). There's also the selfish aspect: I think ProcessWire can compete with much more widely known projects like MODX and Concrete5 when dealing with qualified users of the product. But once bigger projects get their casual social networks involved, we would be outgunned. And the easier the questions are to answer, the more outgunned we might be. I'm guessing the most controversial question I mentioned is probably the one asking for a URL to a site running in the CMS. While that would be a great qualifier, I think you'd still derive benefits in quality, without much loss in quantity, from any questions that ask about the user's experience with the CMS: 1. How many sites have you used with this CMS? [ ] 0 [ ] 1 [ ] 2-3 [ ] More than 3 2. How have you used the CMS? [ ] As a web developer [ ] As a web designer [ ] As an editor (you edit content using the CMS) [ ] As a user (applies to forum software only) [ ] I have not used it 3. What is your favorite feature of this CMS? [Text field] 4. Enter your email address You'd accept the submission, but ultimately exclude the vote from counting if any of these conditions are met: 1. They answer "0" to question 1. 2. They answer "I have not used it" to question 2. 3. They answer "I don't know" or some other meaningless response to question 3. 4. Their email address or IP address matches one for a vote already taken. As a bonus, you'd have the option (if you wanted it) of filtering results by user type (web designer, developer, etc.), experience level with the CMS, and the ability to highlight the most liked features of some products. Meaning, questions like these aren't just about qualification, but about giving you more options with filters and views into the data, now or in the future. These are all just ideas and my opinion only. You've of course got my support and enthusiasm regardless of what direction you go with the voting.

Actually, I'm not thinking. We already have date sorting in the Options section (which sorts at the DB level) so the column heading in this case doesn't matter for date sorting... or at least isn't that useful for it. I can make this date format configurable without any concerns.

It sounds like your version of MySQL won't accept default values for a text field. I've not heard of that before. Perhaps it is some MySQL setting that I've not seen before. Seems like if it won't accept a default value (which we specify a blank string) then it could only be null as a default. Not that it matters much, but I'd prefer the blank string since there is no use for a null here. I agree that removing the default that you did shouldn't cause any issues. I'm curious to see if this issue turns up for anyone else.

I think that supporting multi-day events would just be a matter of adding an end_date field, and consider the existing date field a start_date field. Either that, or you could use a "number of days" field instead of an end_date, but I think having distinct start_date and end_date fields is better because they can support a time component, and they can be queried more easily.

This is planned, just haven't yet found the time to implement it.

The way you describe it, it definitely sounds like something isn't working right with the database then. If you have the opportunity to upgrade, that seems like the right thing to do.

Just add something like this to the top of your events index page. You could compartmentalize this into a LazyCron call, but for such a simple thing it's really not necessary. $events = $pages->find('parent=/events/, date<"-3 months"'); foreach($events as $event) { $event->of(false); $event->addStatus(Page::statusUnpublished); $event->save(); } Btw, when testing something out like this, always comment out the $event->save(); the first time and take a look at what pages get affected by echoing them rather than saving them, the first time around. i.e. // $event->save(); echo "<p>Unpublishing: $event->url</p>"; Once confirmed that it is behaving the way you want, then remove the echo and uncomment your save();

I'm not really sure what could be causing that. Apache and .htaccess know nothing about URL segments... that is only a ProcessWire term. To Apache/.htaccess those URL segments are just a part of the REQUEST_URI like anything else. I would comment out that directive in your .htaccess and look elsewhere (in your .htaccess and in your PW templates) to see where the redirect might be coming from.

I understand what you are trying to do, but can't currently think of a way you can do it (at least not in any straightforward manner). Even if you could do it from the CSS side, there are other factors like sorting (which is designed to work vertically), and the add new items actions, etc.