ryan

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.

Looks quite nice to me. But I'd pose the question to others here: does this usage make it look like this is produced by or endorsed by the ProcessWire project? If so, that would be my only concern. I'm not really looking to tell anyone what they can or can't do (I don't have the legal background to do so), so I figure the best thing I can do is keep track of usage and know who to contact to change it if a lawyer ever says it's necessary.

You would just need to setup the cdn hostname so that it points to the same thing as www (and that your server recognizes it). This is not something you'd setup in htaccess, beyond what's already mentioned. But I would suggest not doing that, as it's not ideal from an SEO perspective to have two hostnames pointing to the same thing.

Correction to Diogo's example: if($user->hasPermission('page-view', $page)) { ... } Assuming that $user is the current user, you can also do this: if($page->viewable()) { ... }

Isn't this kind of a standard though? When I type out a text-based email message, I don't expect the email client to auto-link it unless I put an http:// or https:// in front of it. I suppose it depends on the email client. There's not any way tell for certain if something is a URL if it doesn't have a scheme. Consider the forum user here named aw.be (I'm curious to see if IPB links that). But if it comes down to client-specific stuff, then of course it's safe to do whatever the particular client need is. I'm just speaking on general non-client-specific terms. I would agree though that it's a fairly safe bet to link any text that starts with "www." and is otherwise consistent with the format of a URL. But it does also create an expectation of URLs being auto-linked… and once you take out the "www." there's not a sure way of telling if something is meant to be a hostname or not. Ultimately the scheme is what tells us if it's a URL or not. Otherwise it could just as easily be a filename, a page name, username and any number of other things.

But there should now be one as a result of your ProcessWire installation, which uses /site/ for all your site-specific files. You may be right, it is possible there is something host specific. But just to confirm, it sounds like you found a solution that still works by using your http404 page? Assuming that's working, I would change your header() call to a $session->redirect() call, just to enforce it as a 301 'permanent' redirect, which will be preferable from an SEO perspective. $session->redirect("http://www.communityfound.org");