ryan

I think we are very lucky here to have the maintainer of Textile [Netcarver] using ProcessWire. I started using Textile late in the game, but now that I use it regularly, I like it so much better than Markdown. I wish that I had bundled Textile in the PW core in addition to (or rather than) Markdown. Though if I do it now, then it'll conflict with the /site/modules/ version that anyone already has installed, so would have to come up with a different name for the TextformatterTextile modules. @netcarver, are you interested in managing the TextformatterTextile and TextformatterTextileRestricted modules? These modules basically consist of 1 function all, so there isn't really anything to maintain in them except for the classTextile.php version. If you would like to, let me know and I'll just change the ownership of the modules.processwire.com listing to you so that you can re-point it to your own repo. I'm guessing this would ensure the best consistency between the PW module and classTextile versions. Otherwise, I'm happy to keep them in my GitHub account, but figured I should offer it since you are the maintainer of Textile itself, not to mention a great PW module developer.

Definitely, I think this would be a good thing to do. I'd like to see (and create) more profiles (whether free or commercial). This is one area where we don't have much to offer yet, but it's so easy to do, so I think I'm going to have to dedicate some time to this once 2.3 is out.

Michael, the status checkboxes actually can't be moved to the content tab. But you can add your own checkbox to perform a similar function. If you create a new field called 'toggle_hidden' (or whatever you want to call it) then you would just include "toggle_hidden!=1" in all of your $pages->find() calls.

I agree this does seem really useful, thanks for posting it. I can think of a lot of situations where I really should be using this rather than the existing getRandom(). Rather than adding to PageArray, it seems like the value could extend further than just pages and perhaps it belongs in WireArray instead? (which would be inherited by PageArray) I'm thinking name should be: getRandomInterval(), getRandomTimed() ... or some name that alludes to what differentiates it from getRandom()?

Great module Teppo! Love the output and the whole idea of having this log. I will definitely keep this one installed and look forward to using it. I also like all the details you thought of, like automatic pruning of logs with LazyCron, and keeping track of non-existent users. Very nicely put together. The only thing I might like in some future version is the IP address for each login, just to help for those times when something looks suspicious. Thanks for your work in putting together this module.

Instead of moving these things, why not teach the client how to use the 'settings' tab? These things are kept out of the 'content' tab for a few good reasons: First is that they are things that are less likely to change after the page is created, so keeping them out of the content tab reduces the possibility of mistakes. Second is that these are fields where changes are potentially costly. You change any one of the things on this page and you could affect navigation or site structure. This differentiates them from just about any custom field, which affect the content of the page, rather than the type or structure. Third is that the fields in 'settings' are common among all pages, so it's a means of establishing a baseline consistency among all pages. Rather than the client having to figure out where 'name' or 'hidden' are, they know that no matter where they go, 'name' and 'hidden' are always in the same place. I like to tell clients: "If you know how to edit one page, you know how to edit any page", and they find a lot of comfort in that. Since ProcessWire is driven by custom fields, it's possible for the editing scenario to change a lot from template to template. As a result, it's preferable (IMO) to have the page fundamentals (the things that are always there) kept together for consistency.

Thanks for finding it. I am correcting the master copy here.

Your if() statements will always execute since a PageArray (returned by find) would never resolve to false. The find() could be replaced with a get(), assuming there is only one page with template=student per student. Also there are some out of scope variables, and what looks to be unnecessary foreach() loops. Lastly, the 'name' could use sanitization. I rewrite it like this: if($input->post->submit) foreach($input->post->delete as $s) { $name = wire('sanitizer')->pageName($s); if(!$name || $name !== $s) continue; $dp = $pages->get("template=student, name=$name"); $du = $users->get($name); foreach(array($dp, $du) as $item) { if(!$item->id) continue; $pages->delete($item); echo "<p>$item->path has been deleted!</p>"; } }

Btw, I just now added a replace() method to WireArray so that we'll have the above contained in 1 function for PW 2.3

You might try something like this for replacing an image. You add the new image (which places it at the end) then grab it and insert it before or after the old image. Then you delete the old image. $oldFile = 'myimage.jpg'; $newFile = '/some/path/or/url/myimage2.jpg'; $oldItem = $page->images->get($oldFile); $page->images->add($newFile); $newItem = $page->images->last(); // get the item just added $page->images->insertAfter($newItem, $oldItem); $page->images->delete($oldItem); $page->save();

This one is correct, if I'm understanding what you are trying to do correctly. If you go and uninstall module B, that is actually okay -- it won't stay uninstalled for long. Whenever you request a module via $modules->get('module name'); it goes ahead and re-installs it (if it's not installed). Here is the key: If module A installs module B and actually uses it for something or another, then module A will continue to work because module B will be installed again as soon as module A executes. This behavior is part of this dependency ecosystem. If module A requires module B, that means module B must be installed before it will let you install module A. In the above, you've got both modules requiring each other, which would prevent installation of either. This is a circular reference. I'm not surprised it timed out. Maybe I should account for that situation, but this is the first I've seen someone making a module require itself. This also seems like another kind of circular reference where the behavior would be undefined. If I'm understanding all correctly, I'm guessing you would suggest this: If module A installs module B, then module B should not be un-installable except by module A? I think this probably makes sense. Currently it does not do that, but I don't see any drawbacks in implementing that behavior.

I'm at gym reading tweets between sets so will read/reply better later. But have you looked at the LanguageSupport module that installs/uninstalls its own related modules?

ProcessWire modules are by nature meant to save time. There are 3 modules that I think can be big time savers on almost every project: The MarkupPagerNav module included with ProcessWire is hard to imagine being without. Yet, I was doing pagination without this for a long time before making it, and... things get done a lot quicker now. The MarkupSimpleNavigation module can be a big time saver when it comes to many common navigation scenarios. The FormBuilder module is a big time saver when it comes to creating forms. It's turned the most annoying and consuming part of development (for me at least) into one of the quickest and easiest. When it comes to front-end development, I'll admit that I've always preferred starting from scratch. But lately I've been enjoying what some of the CSS frameworks like Skeleton, Foundation and HTML Kickstart bring to the plate (and Twitter Bootstrap I'm guessing, but have not used it). With the appropriate project, these are huge time savers. The project I'm working on now (for a boarding school) needed to be responsive and very unique in design, and I found Skeleton to be the perfect balance there. It provides just enough to make things responsive, and very little else. That left little room for the design to be influenced by the framework (which was desirable in this case). If I didn't need responsive on a particular project, and could let the design benefit from some framework influence, I'd go straight to HTML Kickstart as the biggest time saving framework. Lastly, I'd say that using the Basic Profile as a starting point has always been a big time saver for me. Almost every site I build needs the core framework of fields and templates included with the basic profile. While all the markup and CSS ultimately get replaced, it saves a lot of time having these things there ready to implement.

I don't want to make assumptions about what people are using the text field for. If you are planning to use HTML, Textile, Markdown, BBCode, etc., then you don't want this Textformatter on. I usually make most of my text fields use Textile or Markdown (rather than HTML Entities) so that I can still have the ability to insert links and have basic formatting when I need it (even for single line text fields like 'title'). If the fields will contain untrusted user input, then I would choose TextileRestricted or BBCode (Markdown is not safe here, as it still allows HTML). Though if you don't need them to have any formatting ability, then I would just stick with HTML Entities, to exclude that possibility. There are just so many legitimate uses of tags in a field that I'd rather someone decide what they plan to use it for rather than us assuming what they will use it for. Still, I can see someone skipping over this not really understanding the security risks, so what may be warranted is for me to have it show a warning when no Textformatter is selected. There are plenty of cases where you actually don't want any Textformatters, but something containing untrusted user input is not one of them.

The main reason why name isn't on the content tab by default is because you could be breaking links (internal or external) every time you change it. It's one of those things that ideally should never change after its been created. But if you do expect changes, I suggest installing the Page Path History module, which will keep track of those changes and setup 301 redirects.

Raymond, I've posted another module that accomplishes this (and more) much better than the one I posted above. And this one actually would remove the 'status' field from the user's visibility as well:

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

Try checking one of the boxes and saving the page. While it'll let you check/uncheck, it shouldn't let you actually save it. So after hitting save, click to somewhere else and come back to the page and you should see that the value did not save. The reason for this is:

I see what you mean, I was forgetting about the status settings. Also, I do the same thing with page 'name', but admittedly have never had a problem with a client changing it when they weren't supposed to. But this is all easy to overcome with a module. I think this will accomplish what you want to do. I've also tested this to confirm, so it should work out of the box. As it is now, it'll deny access to editing of name, parent, template, status for everyone except superuser. But I put in variables at the top where you can add additional templates or roles that should fall-back to the default permission checks as if the module wasn't here. One thing I want to note is that PageEdit doesn't perform a permission check before displaying the status checkboxes. However, it does perform a check before saving them. So the user may see them, but they won't be able to change them (which is probably just as good). Code is pasted below, but I'm also attaching the file if you prefer to download it instead: CustomPagePermissions.module class CustomPagePermissions extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Custom Page Permissions', 'version' => 1, 'summary' => 'Starter/example module to enable customization to page field permissions.', 'singular' => true, 'autoload' => true, ); } // names of fields that you want to deny access to protected $denyFields = array('name', 'status', 'template', 'parent'); // optionally specify names of templates that will be excluded from these permission checks protected $skipTemplates = array(); // optionally specify names of user roles that will be excluded from these permission checks protected $skipRoles = array('superuser'); // attach the hook public function init() { $this->addHookAfter('Page::editable', $this, 'hookPageEditable'); } // perform the editable() check public function hookPageEditable($event) { // if editable() already denied access, then don't continue if(!$event->return) return; // if user has one of the 'skip' roles identified above, then skip permission check foreach($this->skipRoles as $name) if($this->user->hasRole($name)) return; $page = $event->object; $fieldName = $event->arguments(0); // if page template is one you want to skip, then we'll return if(in_array($page->template->name, $this->skipTemplates)) return; // if fieldName is one of those listed, we'll deny access if(in_array($fieldName, $this->denyFields)) $event->return = false; } }

The stuff that you see in that 'system' tab actually for development of ProcessWire itself. It's not meant for use on sites, and may be dangerous to change stuff in there. Likewise, disabling the settings tab isn't something meant for normal pages, and could potentially cause problems since it was really only meant for specific cases with types descending from Page and not Page itself. But even if it were safe, I think it may not necessarily be a good idea because that Settings tab is intended to be hookable for other modules to add functionality if they deem it to fit better in 'settings' than 'content'. A better way to disable specific settings is to disable access to the features that are in settings, all of which are aware of user permissions (except for 'name'). For instance, if you don't want them to be able to change the parent page, then don't give the user's role access to 'page-move' permission. If you don't want the user to be able to change the template, then use the template's family settings to define what's allowed or limit the users access to just that template. That only leaves the page's "name" as something that can be changed in the settings tab. If someone has access to edit a page, they also have access to edit the name. PW does check for access to edit "name" but the permission system doesn't implement it. Meaning it's currently setup for hooks to implement if they choose to. But this will get implemented once we have field-level permission assignments, which are on the to-do list.

Since you are setting your text fields directly from $input->post variables without sanitization/validation, make sure that all of your text fields have the HTML Entities textformatter enabled. To illustrate the potential problem, try putting this into a text field that does not have an HTML Entities textformatter enabled: <script>alert('gotcha!')</script> If you get a "gotcha" alert box, then someone can basically take over the entire page and your site is vulnerable to cross-site scripting attacks. That's why it's really important to make sure any output coming from non-trusted users is always entity encoded.

You should also be able to do this: $biology_students = $pages->find("template=student, subject=/subjects/biology/, sort=title");

This is correct. The files themselves keep their own timestamps, # of bytes, etc., so we don't need to track it separately in the DB.

Thanks for the report. Since there are a lot of DB tables involved with repeaters, which DB table specifically do you mean? Also can you confirm that the deleted page is not still in the trash? (meaning it was really deleted and not trashed)

The current dev branch is meant to be 2.3. I'm planning to add a little more to do it, but will be final before the years end. I do think its safe to use the dev branch if you keep an eye on it. I am currently using the dev branch in all my projects. The only reason I'm not bringing the changes over to master individually is because there are a couple bigger ones in there (database session support and change to blowfish for password hashing). I think those need to accompany a version number for safety. But I could definitely use help testing the dev branch since it will become 2.3 very soon.