ryan

I don't think the delay would be coming from ProcessWire. Most likely client side, styles or javascript. Try removing these and working forwards from there till isolating what it is. Sometimes browsers get in an odd state too, so the first thing to try might just be quitting and reopening your browser. But if that's not it, definitely remove CSS and JS from the equation, and then start adding them back till you isolate it.

You can make any page a settings page. Some of us use the homepage for convenience (since it is the root owner of the pages below it). But you could make your own custom 'settings' template and contain them all there instead if you preferred. I'd also suggest deciding which settings need to be dynamic and which don't. Something like 'site title' may not need to be dynamic. I prefer to store this stuff in $config or with PHP define('key', 'value') calls, either of which you could put in /site/config.php.

You can only pass static strings to the __() function. At least, the translation parser will only be able to find static strings. The only reason you'd put a variable in a call to the __() function, is if you knew the text was already available translated, and wanted to retrieve the translated version. But that text would have had to appear statically, somewhere else in the file. To make a multi-langage image field, you can use a Repeater. Your repeater would contain two fields: 'image' and 'summary'. Make the 'image' field of type Image, and set to to contain max 1 image. Make the 'summary' field of type TextLanguage (or TextareaLanguage). The Image field is the next one on the list to make multi-language capable, so should be within the next major version of ProcessWire.

Thanks Maniqui, this is great info! You are officially our Git advisor, should you choose to accept the job. Actually those 3 lines aren't supposed to be in dev OR master. It appears to be just a duplicate if() statement to the one right below it. It doesn't appear to be a problem, but of course it's unnecessary redundant code. So I will have to remove this from master. I actually have no idea why or how there are duplicate lines there. But thank you for finding it. Great links too, bookmarked and look forward to reading.

Very nice! But it took a long time to load here. Not sure if that's because of the connection that IP is going through, or if it's the result of loading and rendering data for 533 pages (?) in one request. But if you are loading that many pages in one request, it's good to keep in mind that you can only scale so far using that method. Eventually, you'll fill up memory if that table keeps growing. If it's not going to keep growing, then you may want to at least cache it with MarkupCache. Usually if I'm rendering something that's reusable and has 50+ pages loading as a result, I use MarkupCache to cache the output.

Double check that you don't need a more specific URL for this. I'm guessing you might need it to be "/sendEmail.php" instead? I would guess those values have to be escaped if you bundle them in a string like that. To make it simpler, I would suggest changing this to: data: { name: name, email: email, subject: subject, comments: comments }

For front-end use, I would just follow any instructions that come with CKEditor itself. ProcessWire really tries to give you an environment on the front-end where you can implement anything without having to worry about the system itself. The only reason I would use InputfieldCKEditor on the front-end is if you are already using other Inputfields and including their scripts, css, etc. Otherwise, better to just use CKEditor and implement the same way they do on their website.

InputfieldEmail does this validation for you. PHP's built-in mail() function makes this pretty simple: $body = "This is the message body"; $subject = "Web Contact"; $emailFrom = $form->get('email')->value; $emailTo = 'you@domain.com'; mail($emailTo, $subject, $body, "From: $emailFrom");

Thanks Radek, will do! This is on my to-do list.

Matthew is already working on a site directory for us, so he may have some thoughts too (?). I think if someone wants to put time towards making ProcessWire look good, that's always a good thing. One thing is for sure, we definitely need more showcasing of sites built with ProcessWire. If there is more than one showcase, I don't see that as a problem at all. Just more opportunity to reach a broader audience.

I would think that whatever you pass in would overwrite any defaults already present? That way, if you want to override something, you can. If you don't want to, then you leave it out. I guess the question is whether there is any value to overwriting the variables that are already populated in the template. The only one that seems like it could have value would be $page. Until I think about it a little more and… what would be the point of calling $page->render(...) if you were going to overwrite the $page in it. It would be more logical to just find the $page you want and call its render() method instead. Maybe throwing an Exception does make sense. Though need to think about it a little more.

I'm not clear about the question. What is the source of the URL segments you'd want to use?

This makes the events consistent with how they are in the Pages class, which I think is a good thing. They are more reliable to standardize upon because, for example, saved() is called only after an item has been saved without error, and saveReady() is called only after its been confirmed the item will definitely be saved (no conditions to prevent). Without these, your hooked functions have to consider these things themselves (at least, if you want them to be thorough). Granted, there are more potential conditions within Pages than here, but these are hooks that probably belong here either way. I was just looking for a good reason to add them. While I think you may be able to do what you need without them, feel free to use them if helpful, because they belong here.

This sounds awesome mindplay.dk! That's a valid concern, since modules or other API usages that are adding/manipulating templates/fields would not be triggered from the Process ones. Though if you only wanted to capture changes made interactively, that would be the place to do it. Attached are replacements for /wire/core/SaveableItems.php and /wire/core/Fields.php. They contain additional hooks, which I think may be more what you are looking for. Let me know if these work out, and I'll commit them to the core. I'm a little short on time this afternoon, so haven't had a chance to try them myself, though the additions are very minor and simple so can't think of any reason why they wouldn't work. mindplay.zip I added a few hooks to SaveableItems.php which is used by both Fields and Templates. You can hook these either by wire('fields')->addHook('methodToHook', $this, 'yourMethod') or $this->addHook('Fields::methodToHook', $this, 'yourMethod'). To operate on templates, you would replace 'fields' with 'templates'. Here are the hooks, and they work exactly like their Pages class counterparts: public function ___saveReady(Saveable $item); public function ___deleteReady(Saveable $item); public function ___saved(Saveable $item); public function ___added(Saveable $item); public function ___deleted(Saveable $item); These two were also added to the Fields class (in the attached zip): public function ___changedType(Saveable $item, Fieldtype $fromType, Fieldtype $toType); public function ___changeTypeReady(Saveable $item, Fieldtype $fromType, Fieldtype $toType); For all of those above, it doesn't matter if you hook before or after. For the existing hooks that were already there, it does matter whether you hook before or after. Though not sure if you necessarily need any of these: protected function ___changeFieldtype(Field $field); // Fields class only public function ___saveFieldgroupContext(Field $field, Fieldgroup $fieldgroup); // Fields class only public function ___clone(Saveable $item); public function ___delete(Saveable $item); public function ___save(Saveable $item); protected function ___load(WireArray $items, $selectors = null); Let me know if there is anything else I can add/adjust to facilitiate what you are working on.

I agree with Soma, it sounds very doable to me. Let us know if you run into any specific problems as you go.

It's in kind of small text on the MySQL config screen:

I'm not clear about what the pages are. Can you post a screenshot from your admin so we can see?

It's in the dev branch now

Thanks Soma, that one is fixed now.

Maniqui, Thanks for your suggestions. Regarding the missing commits, it appears that GitHub is not giving the correct information about this, or maybe I'm misunderstanding. All of those updates are on both branches. I went through each of the items to confirm. As an example, look at the second one 9b3039d which says "Fix issue with RepeaterPageArray lacking a makeNew() method." But I can go and see that this was updated on both branches: master and dev. The same goes for all the other updates. Let me know if I'm missing something. I will go ahead and tag it 2.3.0 here. But I'm not sure this would have resolved the 2.2.9 and 2.2.9-final, because I didn't realize 2.2.9 had commits after the original tag until I was merging in 2.3. I honestly don't know what happened there, but probably some workflow/user error on my part. What would have solved it here is if I had another component to the version number so that the dev branch could have an incrementing version that didn't potentially conflict with a master version. That way someone could say, I'm running 2.3.0.3 or "2.3.0 dev 3" and I know by that extra "3" at the end that it's a dev branch revision. Then once ready to merge to master, it would become 2.3.1 on master and 2.3.1.0 in dev. This seems like a workable route to me, but let me know if you can think of a better route?

I just posted an update to the LanguageSupportPageNames module that appears in the 2.3 dev branch. The screenshot explains it best: Basically, you can uncheck the "active" box for any language, and that page becomes unpublished, for that language only. It behaves the same way as an unpublished page, in that it doesn't show up in searches, and produces a 404 if you try to view it (unless it's editable, in which case you can still see it). You don't see a checkbox next to the default language, because that one is controlled the same way as before (via the page's unpublished status).

I don't really see HTML tags being indexed as a problem. I've taken advantage of that on a few occasions and was glad it was there. Honestly, I've never had the need for more than the built-in text searching capabilities. Though my needs aren't everyone's either, so not saying there wouldn't be a need. There have been times when one operator or another better suited a particular client, whether %= or ~= or *=, but I've never had the need to use an external solution. There have been one or two instances where I had a large quantity of fields that needed to be included in the search, and it became a potential bottleneck. This is part of the reason why the FieldtypeCache exists. You can bundle all of your text fields into one, and then search the cache rather than the individual fields. So you would search for "field%=some text" rather than "field1|field2|field3|field4%=some text". It works quite well for this. It's been awhile since I've had the need to use it, but it's one of the original core Fieldtypes and worth looking at if you run into a similar issue of too many fields to search, or needing those fields to be in the same block for ranking purposes. (Search ranking works a little bit differently when the combination of fields is ranked vs. individually ranked as separate fields). As for external search engines, I think it would be hard to beat something like Google CSE (if that's what they still call it). I've also used Sphider as a self hosted PHP-based solution, and was quite happy with it at the time… though this was before ProcessWire existed. But it still seems to be an active, and highest rated (to Google) PHP search engine. It does include the ability to index PDF, DOC and other files, though requires external converters. If I recall, it works quite well for that though.

Great site Nico!

If you don't want to re-trace steps of page, field or template creation, you may want to share a database server with your team. It doesn't matter what system you are working in, if everyone is running their own copy of the database, that's something that needs to be resolved when pushing them back together. Another option is to use the API to create your pages/fields/templates and script them. But the reality is, most of one's work in ProcessWire typically isn't in the creation of these things–instead, it's working in code. So your best bet is to write code that doesn't rely upon specific database IDs, and instead abstract to retrieving things by name, path, template, etc.

I haven't seen that particular error in a long time. What version of ProcessWire? The LanguageSupportPageNames module is only advised for development and or testing purposes at present. It will be ready to use in production over the next month.