ryan

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");

I respect Drupal, but strongly dislike using and developing in it. This comes from a couple years of developing sites in it. The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious). People may use Drupal at large scale, but I don't believe the product itself was ever truly designed for it. Like with WordPress, being used at the large scale is something that happend to Drupal rather than something it made happen. Drupal is a pig that people have affixed wings to because there wasn't any other way to do it at the time. You see similar things happen with the other big platforms (WordPress, Joomla). As far as pigs go, Drupal is a good one. There are some things to respect (though not necessarily agree with) about Drupal's roots and the original thinking behind it. There's no doubt that it is far better than Joomla, for anyone that cares about this stuff. Beyond that, where it excels is in all the 3rd party stuff written for it, to do just about anything. It's a diesel-powered cuisinart in that respect… whatever you need to blend, it will blend… but it'll be messy. Working at large scale, 3rd parties have built all kinds of caching, CDN and load shifting things to throw on top the pile (and likewise with WordPress). Even a pig can fly if you strap wings on to it. And Drupal has a lot of folks thoroughly invested in it to the point where they are making that pig fly. Drupal is also such a household name that it represents a low-risk position for decision makers (low risk of job loss from choosing Drupal). None of this makes it a good product, just a safe one for people that don't know any better. But for people that do know the difference, we want a panther, not a pig.

I like the idea of this, but one potential issue: not all URLs begin with 'www'. For instance, you can't access processwire.com from www.processwire.com (it'll redirect you). So the proper way to link processwire.com is just http://processwire.com. Another example would be http://store.di.net, which is something different from www.di.net. I think what would be better is to have it auto-link URLs that start with a http:// or https:// on the front. That way there's not much chance of it autolinking things that it shouldn't. The regex would have to check that the http:// doesn't have a quote or equals sign in front of it (indicating an already-linked URL). This could be done by checking to make sure the http:// is either at the beginning of the source string (no characters preceding http://) or the preceding character is [^\w"\'] meaning not a word character, a double quote, a single quote, or an equals sign. I think that could be placed in a lookbehind to avoid including the preceding character in the match. http://www.regular-expressions.info/lookaround.html -- edit: looks like the forum has troubles with it's URL matching

Thanks, looks like it's just the startLabel ('Add') that should be translatable, as it should pull the cancel label from the translation the InputfieldPageListSelect module -- I will fix this, as well as make the startLabel translatable in the dev branch.

Thanks, I will add this to the core!

You should be able to manually manipulate the ID. But there will be some loops to jump through with certain fields that may require manual intervention (page references, file fields, repeaters)… and this is where things get tricky. So I think you are better off copying data back to the original page rather than deleting the original and changing the ID of the clone. There will still be challenges, but I think it's the safer bet (though not really 100% certain). Regarding the repeater fields, I'm not really sure how to approach this one yet. I would be inclined to skip over repeater fields when it comes to this feature, for the short term. This is a big question and I think we can answer it, but it's going to take some time and research.

I think we might need more description. Are you referring to the blog profile? Can you tell more about the specific context of the question?

For the other part of it, in preventing the duplicates. As mentioned before, the pages you retrieve are already going to be unique. But like you said, you may have duplicate field values even among unique pages. Lets say that you wanted to guarantee the uniqueness of a 'title' field, for example: $uniqueResults = array(); foreach($results as $resultPage) { $uniqueResults[$resultPage->title] = $resultPage; } Following that, there will be no pages with duplicate titles in your $uniqueResults array. You can take the same approach with any other field(s). Though make sure your field resolves to a string before using it as a key in your $uniqueResults array.

Passwords are in a table called field_password. They are hashed and salted, and not reversible, so no way to set or change them without going directly through the API.

Check that output formatting is enabled for $user. Add $user->of(true); to the top of Soma's example and see if it makes any difference?