ryan

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.

Thanks Arjen! You can use it forever. The 1 year applies to the support and upgrades.

The nice thing about language alternate fields is that there isn't really much going on behind the scenes, so it's pretty straightforward to perform the kind of detection you are asking about. Since each language is represented by a different field, you just have to check those fields: if($page->pdf_file_french) { echo "PDF file is available in French "; if($user->language->name == 'french') echo "and pdf_file is the French version."; }

Stephen, thanks for posting this. There are a huge amount of good tips here!

Thanks guys, all that you are saying makes sense and I agree.

Memory isn't an unlimited resource, so there is always a limit as to how many pages you can keep in memory at once. You'd need to code this in a scalable manner, which means find a way to do it that doesn't require loading thousands of pages in memory at once. I'm not sure I understand the code example enough to suggest an alternative. But you can always go directly in with an SQL query ($db->query) if you need to do something that you can't accomplish with the $pages->find(). One other thing I want to mention is that your $selection variable here is open to selector injection. Make sure you run any values you get through $sanitizer->selectorValue(), or a more specific $sanitizer function, before placing them in a selector string. For example: // use selectorVaue when the value will be a freeform string $ip = $sanitizer->selectorValue($input->post->ip); $selection .= ", ip=$ip"; // sanitize with pageName when you expect the value to be [-_.a-z0-9] $action = $sanitizer->pageName($input->post->action); $selection .= ", action=$action"; // typecast to an integer when you expect the value to be a number $us = (int) $input->post->user; $selection .= ", users=$us";

Sorry Steve, I've sent you down the wrong path. The 'name' field can't be used with partial match selectors, so there isn't really any point in using the autocomplete unless you want to have to type out the whole username to find it. Sometimes I have to try things out before I realize them. If you wanted to do that, below is an example how: $field = $m->get("InputfieldPageAutocomplete") ->set('label', 'Select individuals you wish to notify') ->attr('id+name', 'users') ->set('parent_id', $this->config->usersPageID ) ->set('labelFieldName', 'name') ->set('searchFields', 'name') ->set('operator', '=') ->set('columnWidth', 50) ->attr('value', explode("|", $user_ids) );

I see what you mean. Sorry for the confusion this may have caused. I will think more here about how to handle this. I don't want it interfering with API usage such as yours, but do want it to be able to still work with any login form (whether ProcessLogin or a custom one). Initially I'm thinking maybe I should just have it throw an Exception rather than a $this->error(). Errors communicated via $this->error() require something to report them (like the admin template), so this could be hard to find in API usage. Whereas an Exception would be hard to miss. Beyond this, I think a way to disable SessionLoginThrottle at runtime would be worthwhile for a case like this too.

I'm not aware of any issues with drag-n-drop uploads in Firefox. Just tested (15.0.1) and works well here at least. Nico by any chance are you using Safari? I know for certain that drag-drop uploads don't work there, because Safari doesn't implement the HTML5 APIs to support it.

This continues to look really great! One possible suggestion would be to use the PageAutocomplete Inputfield for the individual users, just because some people might actually have thousands of users. This may be too much for an asmSelect.

Unless you are doing some one-time import/export, you usually want to avoid actions that require loading huge amounts of pages in one request. This is a non-sustainable way of building a web site in any platform, because eventually you will run out of memory. If you are making a small web site, then you don't need to worry about it. But if you are making something that will grow big, you need to place limits on API calls that could might lots of pages (as in, use the "limit=n" in your selectors). Going directly to MySQL is certainly a fine way to go if you need to perform some query that can't easily be performed in the API. Though admittedly, I almost never need to do this, but there's no harm in doing it. One other thing I want to mention is the $pages->count() function, which works exactly like $pages->find() but instead returns a count of the matching pages. It does this without actually loading the pages it's counting, so may be applicable here.

I have this same issue when doing one-time migrations of finished sites on my localhost MAMP/dev server (which runs sites off subdirs) to the live server. But the solution is really simple. When I export the database to an SQL dump (via PhpMyAdmin), I drag the resulting SQL file into TextWrangler/BBedit, and perform a search/replace: "/newsite/" => "/". Then I import it to new server (again via PhpMyAdmin). Problem solved on 5 seconds.