ryan

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.

Actually there is. http://modules.processwire.com/categories/textformatter/

It looks like Twitter must have re-enabled the RSS feed? I've noticed the client site installations where I was using MarkupTwitterFeed have started working again.

Anything that is under /site/ is protected during upgrades. These are all your site-specific files and PW doesn't mess with them.

This points to the problem. Apache is not even reading your htaccess, so it doesn't matter what you put it in, it will get ignored. GoDaddy is big enough of a company that I'm sure they have provisions for enabling it, as very few CMSs would function optimally without it. But it's a little surprising it wouldn't be enabled by default. Double check that the file is in the right place (the same dir as PW's index.php) and that it is named ".htaccess" (with the dot in front) and that the file is globally readable. If it's still not working, this is something you probably need to contact GoDaddy about as I think only they would know how to enable it in their system. I have used GoDaddy's hosting via a client's account, and all worked without issue (.htaccess enabled, etc.), so I'm also wondering if you might be on some other kind of (non unix) account.

PW pulls this from GitHub directly and caches it for a period of time. It looks like GitHub gave us a page with a meta redirect in it on the last pull... I'm guessing it was a "GitHub is down, try again" type thing that reloads itself. Anyway, I cleared the cache and that seems to have fixed it. Thanks for letting me know.

It's not a good idea for 'autoload' to be the only condition necessary to add script or css/style files. That's because some (including me) use things like $config->scripts and $config->styles on the front-end of sites, and don't want it to be populated with files irrelevant to my site. Furthermore, we can't assume that we always know what ProcessWire is being used for (it might not have anything to do with HTML), so it's just taking up extra memory if some autoload module is populating filenames when they won't ever be used. This is why none of PW's modules that deal with script/style files are autoload, and also why Process and ModuleJS module interfaces are not autoload. Process modules are on-demand, but if you have a Process module that you've made autoload, then you'd want to manually load any script/style files in the relevant execute() method -- this ensures they won't get loaded unless they'll actually be used. The ModuleJS class is different, as it's really not intended to be autoload at all, so there's not really any use in combining ModuleJS with autoload. The whole idea of javascript or css is specific to a runtime and on-demand context. And this is how it's happening in the admin template, as it is what ultimately triggers the JqueryCore and JqueryUI libraries to be loaded. And this is the time that they get placed into the $config->scripts array. So we'd just have to find some way to hook after that takes place, but before the markup of the page is generated. I think this may work for an autoload module: public function ready() { if($this->page->template == 'admin') $this->addHookBefore('ProcessController::execute', $this, 'hookExecute'); } public function hookExecute(HookEvent $event) { $this->config->scripts->add(' your script file '); }

To do this, I'd suggest copying the contents of /wire/templates-admin/ to /site/templates-admin/ and then make the edits to your version in /site/templates-admin/. That way it won't get overwritten during upgrades. However, sometimes the admin theme does get updated, so you may want to note the edits that you make in case you need to make them again during a future upgrade.

Thanks Stephen! I've created you an account on the wiki. Username is the same as your username here, and password is your email address. Go ahead and change the password once you login. I see the wiki as a place to post documentation that will be eventually moved to the main site, and I think it's pretty good for this purpose. I agree with Pete that we'll eventually have a PW-based solution to replace the Wiki too, but now that we've gotten the spammers out of the Wiki it seems to work pretty well.