ryan

I don't know for sure, but am guessing yes. But that gets down into the jQuery plugin. I'm not looking to modify the jQuery plugin, but we can always offer suggestions to the author of it. This is again the behavior of the jQuery plugin. I suppose we could disable the plugin if there is only one image, but I'd rather leave the plugin to do whatever it does and upgrade it as the author puts out new versions.

I don't think that the oldfile.php is the problem, because it has a javascript save() (whatever that refers to), not a ProcessWire one. But looking in your Modules.pdf, I can see you've got a large amount of 3rd party modules installed. The more 3rd party modules you have installed, the more you have to keep track of in terms of versions and potential interactions. This is true of any CMS. It really expands the scope of where the problem might lie. I can also see by the PDF that you've switched back to PW stable? Just wanted to confirm that you are no longer on dev? If that is the case, make sure that you replaced the entire /wire/ directory when switching between stable and dev. The best way to do that is to rename the old wire directory, and then upload the new one from scratch, then remove the old one once you are sure it works. So far it sounds like we can narrow the issues down to two things: #1) large amounts of pages got unpublished; and #2) template access control settings disappeared. I'm not convinced that these things are related. So lets take a look at them separately. For #1 I would look at what modules can publish/unpublish, because ProcessWire has no mass-unpublishing capabilities in the core. In looking at your modules list, it looks to me like: SchedulePages, Page Publish/Unpublish and Batcher (if you had it installed). Of those, only SchedulePages and Batcher can do mass unpublishing, and it doesn't look like Batcher is installed. So I took a closer look at SchedulePages: the module looks to be nicely coded, but I spotted a problem on this line. // Select published sites with a publish_until date add them to an array. $published = wire("pages")->find("status=published, publish_until>0"); It's referring to "status=published" and "published" is not a status keyword recognized by ProcessWire. I think that the author really meant to do: "status<" . Page::statusUnpublished, because there is no published flag in PW, only an unpublished flag (since it's technically a bitmask). Why don't you try to run this selector "status=published, publish_until>0" in your Setup > Selector test, and see what it finds. Reading the rest of the function in SchedulePages, it still seems unlikely that this would be responsible for your unpublishing unless your server's system time inadvertently got reset to something earlier than it was supposed to be? For instance, what if your web host installed an update and had the server's time messed up for a few minutes? That could feasibly produce a mass unpublish event since this module performs unpublish actions connected with time. Edit: also want to add that it sounds like in your situation with numerous editors, a 1-click "Page Publish/Unpublish" module might be a little bit dangerous, as someone could unintentionally unpublish a page very easily without meaning to. You might want to uninstall this module, just to rule it out as being a problem. In this day and age when we can butt-dial people on our cell phones, we can also click links without knowing it. So a 1-click unpublish action is always going to be a potential problem. For #2, template permissions disappearing, this opens more questions: On how many templates are you defining access? Are there any other "superusers" in the system, besides yourself? How many roles are you working with? (just one editor role?) Do any of these roles have permissions to modify admin pages? You mentioned a "flooded with phone calls" – how many users are we talking about that have access to the admin, and are all trusted users? Are all of your users using secure passwords?

That seems unusual that the class exists even though it isn't installed? Thanks for finding that and posting a fix, I will update! …Though if the PDO class exists, then the PDO:: constants would presumably also be defined (since they are defined in the class). So I think another type of check would be necessary. But what kind of check, I have no idea. I'm going to hunt around stackexchange and maybe look into what other CMSs using PDO are doing.

You must have had the original HTMLPurifier module, which I mistakenly based the version number of the HTMLPurifier version number. I fixed that in the next one. Sorry about that. I just now pushed an update to CKEditor that should fix this.

@ceberlin: not a problem, but for the future please try to avoid posting the same message in two topics–I see this same message as a new topic, so I'll delete that one and reply to this one. It sounds like you are using a module that modifies ProcessWire's default access control: Page Edit Field Permission. So it's very possible that the rights you see in your page settings are incorrect. Instead, pay more attention to what your templates actually say, and how you've configured the PageEditFieldPermission module. Those have authority. The info you see in page settings is an informational-only table that reflects known static permissions and says nothing about runtime permissions attached from other modules or hooks. Most of the changes in the dev branch are specific to the LanguageSupportPageNames module and multi-language support in general. Are you using LanguageSupportPageNames or any kind of multi-language support? When you updated to the newest dev version (2.3.2), what version were you running before that? I replied to your comment on GitHub: Why linking to the mod settings pages in the admin of your site? I was thinking it might be because you want me to look at your settings for those modules, but note I can't see them since I am not logged into your admin. Are there any other 3rd party modules you have installed? If so, can you mention them, or post a screenshot. We'd want to see all modules that appear on the "site" tab of your modules screen. Also, since all of this is rather mysterious, I would also suggest checking your template files. Do you have any instances of save() in any template files or files they include? If I had experienced the same issues you have, the first thing I would do is check where I am saving pages (or anything else) in my site. I would suggest doing a: grep "save()" /site/templates/* Please post the code for any sections that perform a save of anything in your template files.

I don't think that is CollagePlus, since this module doesn't generate any images. Chances are you've just got some really large images. This more likely just has to do with the way PW's image selection has always worked. When designing PW's image selection, there was a conscious decision not to have it generate any images beyond the original. The benefit is that you don't end up with endless copies of images that aren't ever used on the front-end. The drawback is that if you've got big images, that can slow things down. But that's going to be the case regardless of whether you are using this module or not.

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.