ryan

Sounds like you've got it right.

Nothing will be as fast as going straight to a dedicated targeted SQL query like that. But if you wanted to use PW selectors, this is still quite fast: for($n = ord('A'); $n <= ord('Z'); $n++) { $letter = chr($n); $cnt = $pages->count("surname^=$letter"); echo "<li>$letter - $cnt people</li>"; }

Global shouldn't be used with repeaters. Sorry guys, I thought I had that option disabled. I will fix.

Manual sorting is intended for reasonably sized lists, like navigation. For large groups of pages that have a chronological basis, you should always use some kind of date sorting. If you need to go outside that in certain instances, then add a "sticky" or "featured" checkbox, so that the client can override what gets shown first on the front-end when they want to. For example, if we wanted to retrieve a list of all news articles by date, but with "featured" ones showing up first, we could do this: $articles = $pages->find("template=article, sort=-featured, sort=-date");

Here you go: http://modules.processwire.com/modules/fieldtype-text-unique/

I've looked into this, and don't think it's got anything to do with use of a language pack or admin theme. I tried executing the query manually in PhpMyAdmin and MySQL simply doesn't trigger an error when inserting duplicate values. It just skips the query. Maybe there are some conditions under which it will report an error, but not that I could find. I think the problem is that the query for inserting/updating fields looks like this: The "ON DUPLICATE KEY" part is where it's at. But we need that, otherwise we'd have to add another select to every insert/update just to see if something is already present. So it looks like any future fieldtype that supports a UNIQUE index would have to implement it's own savePageField() method with some more overhead to check things out and decide whether to insert or update. As a result, you can have a UNIQUE index right now, but it's just being enforced rather than reported. But making a new FieldtypeTextUnique or something like that would be a way to solve it pretty easily.

Blowfish hashing was added to PHP in 5.3, so any version 5.3 and newer supports it. However, a security problem was found in versions of PHP 5.3 prior to 5.3.7, so they fixed it. Newer versions of PHP are still compatible with the old, but versions prior to 5.3.7 are not compatible with passwords generated on newer versions of PHP. Since your host is using PHP 5.3.3, this is likely why you ran into an issue. But a commercial hosting provider should probably not be using a PHP version earlier than 5.3.7 due to that security issue. So the workaround is probably not a good idea since it is circumventing that. I strongly recommend asking your host to upgrade the PHP version.

For storing that scale of data, I think you'd want to have your module create it's own DB table(s) to store it in. Several modules do this. They create their tables via the __install() method, and drop them via the __uninstall() method.

While I don't understand what WillyC is saying, his code is correct. Try "body%=grass, body%=seed" so that you are requiring both terms to be present somewhere in the target text. While that would match 'grasses' and 'seeding', it would also match 'seagrass' and 'birdseed', which you may not want. In that case, you would want to replace the %= with *=, which will use the fulltext index. Because the individual words are indexed, it would match 'grasses' and 'seeding', but not 'seagrass' and 'birdseed'. Also your raw SQL would not work because it would only find fields that begin with the word "grass" AND "seed" – an impossible condition.

Soma, while I wasn't able to duplicate that here, I was able to find a bug when using just parent.title, so I'm wondering if it might also be responsible for the result you were getting. Can you try the latest dev branch and let me know if you are still experiencing the error?

This is true as the requests are delivered as static HTML files. So it doesn't touch the DB unless the request isn't cached. It is a great way to let your server handle a lot more traffic. But regardless of what caching is in place, if you start to see a "too many connections" message regularly, then it's time to talk to your web host to see if the amount of traffic you are getting would benefit from a higher-end hosting plan. There are also cases with some web hosts where the resources are simply oversold and you might see those kinds of MySQL error messages even if you aren't getting a lot of traffic. In those cases, it's a good idea to find a new web host.

You can get by without the symlinks option. It's there because I tend to make regular use of symlinks, and am guessing others do too. But nothing in PW actually requires it.

If something triggers a fatal error, then the save can't be performed. Attempting to move a page somewhere that it's not allowed aborts the save. Also, template changes are confirmed with the user if the new template contains different fields. As a result, it has to be handled as a separate operation.

The "missing required field" error message is translatable in this file: /wire/core/InputfieldWrapper.php

Textformatters are intended for front-end rather than back-end. So you won't see the results of a Textformatter in the admin side. However, if you apply the SmartyPants Textformatter to any text field (Fields > edit field > Details > Text formatters), you should see the results on the front-end.

I'm planning to bring the same import/export system that's in FormBuilder to Fields and Templates.

What you are describing sounds very much like a custom application. It also sounds a lot more like a CRM than CMS. You could certainly do it in ProcessWire, but you are going to be in for some custom coding no matter what system you build it in. Whether using ProcessWire or another system, I recommend that you hire an expert to build this for you. Also, since everything you've mentioned is more specific to a CRM, I also recommend evaluating software like Salesforce for your needs. You can easily send data submitted from a website into into Salesforce using their web-to-lead forms. ProcessWire Form Builder can also submit data to Salesforce (and other services) natively.

The ProcessWire 404 will look like your site. The Apache 404 will look like plain text. Though I actually think this is mod_security either way. I think this is something that only your host can answer. Though if someone else knows better, hopefully they will reply.

I was wrong, the PageList won't work without Javascript at present. ProcessWire just delivers JSON for the PageList, and the markup is actually rendered in Javascript. Try this URL for an example of the output that ProcessPageList produces: /processwire/page/?id=1&render=JSON

We'll be adding more configurability to repeaters in the next version or so, including an option to have them collapsed by default (the repeater items themselves), ability to control labels of repeater items, and automatic sorting.

In ProcessWire you need to set: Who, What and Where. You've got the Who and the What, but not the Where. The "Where" is typically defined by template, though can also be controlled by hooks.

What is on line 1 column 2? That sounds like the first element in the file. I am guessing that a PHP error message is appearing where the start of the RSS should be. Either that or you have whitespace before the <?php tag in your template file. Viewing the source of the RSS feed should reveal what the issue is.

Go ahead and make your module implement ConfigurableModule, even if you don't want any interactive configuration: class MyModule extends WireData implements Module, ConfigurableModule { Add a getModuleConfigInputfields function to your class that just does this: public function getModuleConfigInputfields(array $data) { return new InputfieldWrapper(); } For data that you want to store, call upon the $modules API var like this: $data = array('foo' => 'hello', 'bar' => 'goodbye'); wire('modules')->saveModuleConfigData($this, $data); For data that you want to retrieve: $data = wire('modules')->getModuleConfigData($this); Your config data will be populated to your module automatically after __construct() but before init(). As a result, you might want to set default values in your __construct(): public function __construct() { $this->set('foo', 'hi'); $this->set('bar', 'bye'); } public function init() { // $this->foo is now 'hello' (not 'hi') // $this->bar is now 'goodbye' (not 'bye') } Using this method, your module can always access it's config data directly via $this->foo and $this->bar. Meaning, you probably won't ever need to use the getModuleConfigData() function, but it's good to know its there. However, you will need to use the saveModuleConfigData() function since you are saving configuration data non-interactively.

That's unusual. Are you getting an Apache 404 or a ProcessWire 404? If the file actually exists and you are getting a 404, chances are that Apache can't read it (i.e. file is not readable) – double check the file permissions.

Not sure how I missed that. I will correct and update to the dev branch today. Thanks!