ryan

CollagePlus is a jQuery plugin by Ed Lea. It takes a list of images and converts it to a nicely formatted grid. With this module, we use the CollagePlus plugin to produce nice grid output for ProcessWire image selection. This applies to the images that you select when clicking the image icon from the rich text editor (TinyMCE or CKEditor). The idea for this is from the great Unify admin theme for ProcessWire by @adamspruijt. To use, simply install the module and it is ready to go. Requirements: This module should run on any version of ProcessWire. But to be on the safe side, it would be best to use version 2.2 or newer. If you are using version 2.3.1 (dev branch) or newer this module makes use of conditional autoload for increased efficiency. Download: http://mods.pw/54 or https://github.com/ryancramerdesign/JqueryCollagePlus or install via Soma's ModulesManager. For those running ProcessWire 2.3.2 or newer, you can also install it from your admin: Modules > new > class: JqueryCollagePlus.

Thanks Alessio, I will try to get this setup today.

Another approach is to do it with javascript. I like this method because it's just a progressive enhancement that uses the existing alt attributes (no duplication of text in the request). This is the method I used in the Foundation site profile, which takes the image "alt" attribute and expands it to a caption, like those seen on this page. Here's the JS that does it.

Check to make sure you have the latest version of MarkupHTMLPurifier. Based on the error message, I'm guessing you don't?

Guest means that no user is specifically logged in. But for things like your own bootstrapped scripts or other API usage, you can create a user specific to that need. Then in instances where you want them to be the current user (rather than guest) you can do a call like this: $u = wire('user'); // save current user, if you want to $users->setCurrentUser($users->get('api')); // set new user: api // // .. your code that does stuff // $users->setCurrentUser($u); // set back to the previous user, if you want to

From what Soma said, sounds like maybe it isn't that complex. I don't have much bandwidth to get into it now, but if anyone else wants to figure out how to do it and make a test case, we could support it in the core.

Radek–Thanks for your work in keeping this language pack up-to-date!

Thanks for creating this module Alevine. If you'd like, post to the modules directory at http://modules.processwire.com/add/

Ignore my mention of find()->first(). Looks like I was writing one thing, and changed my mind by the time I got to the code. Using first() would be fine, but I opted to just if(count($field_dupe_check)) instead. It should exclude trash unless you add "include=all" to it. No, because I used get() rather than find(). get() only ever returns 1 page. find() can return any number of pages. TextUnique enforces the uniqueness via a database index. So it's not necessary for you to perform your own checks, unless you want to manage the flow control yourself. Another way to do it would be to capture the WireDatabaseException that gets thrown, but I think your method is fine.

_('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.