ryan

Great module Soma! Tested it out and worked nicely. Only thing I'm wondering about is the name: ProcessTools? How about something that better describes what it does, like ProcessPageAdder or ProcessBatchPages or something like that?

I wonder why this is the case, and if there's anything we can do about it. Seems unusual that Google's algo would be so different in Germany. I'm wondering if we need to do anything to indicate that we are "German friendly" or something to make Google like us better there. I would guess I account for 90% of the US traffic.

The result I reported was when not logged in to Google. Searching for Open Source CMS shows us on page 2, second to last result, and still does when I try it now. Tried it over the iPhone (AT&T network) just to confirm. If I'm logged into Google, it appears higher, but also says "You and Antti Peisa Liked this" or something to that effect. Also, we are #1 for the term Open Source CMF, but apparently that's not a very competitive term because I don't see it showing up in our search logs at all. I think there are all kinds of factors that can affect where something appears in Google, even from data center to data center. Though I am surprised it's now showing up for you. Can you double check? By Country: By Continent:

The latest version of Form Builder (0.1.7) now has a File Upload input type, so we're a little ahead of schedule on having this ready. It's currently in beta test, but available for anyone that wants to try it out as a download from the Form Builder support board. So for anyone that was waiting for file upload capability in Form Builder forms, we've now got it.

I think it just depends on the needs of the site. I'm guessing every site will have a little bit different needs. I tend to veer towards keeping no 3rd party modules installed for my starting point, and then install them as I need them. The ModulesManager might be the best candidate to have installed since it'll make installation and upgrades of any other modules a piece of cake.

Gazley, sorry I'm about a day behind on messages here. The error you are getting indicates the FormBuilder module is getting included twice somehow. I'm not sure how this would happen, so definitely a mystery. But since there was corruption in your fields table, it certainly seems possible there could be corruption in your modules table too (maybe 2 entries for FormBuilder?). And if there's corruption in one place, then there's very likely a bigger problem. Any idea how things started getting corrupted here? You might want to start with a fresh copy from your local server, because clearly something was lost in the migration. What version of PHP and MySQL is the new server running? I also think WillyC's suggestions are good, but they are plugging holes rather than finding what's creating the holes. I wouldn't be comfortable knowing that somehow the data in tables was changing after doing a simple export/import. Whatever is causing that is very likely the source of the problem. First thing I'd do is look at the DB dump file to see if it contains a proper entry for your 'summary_on_home' field. If it does, then the problem is likely occurring during import to your new server. If it doesn't, then the problem is likely with the export from your local server.

Interesting, I wonder how one gets listed there, or if it's just controlled by the owner of it. I looked around it a bit but didn't see any way to submit an application to it.

I'm not sure I understand the question, but I should be able to answer to anything Form Builder related. Can you post more details (in the Forum Builder support forum)?

This is a bug. I'd actually fixed this one a week or two ago on the dev branch but hadn't carried it over to master. I just put it on master so it should be fixed now.

I'd suggest changing this line: if ($pages->find("template=blog-article, tags=$tag")->count() > 0) { To this: if ($pages->count("template=blog-article, tags=$tag") > 0) { The reason is that find() loads all those pages, whereas count() just counts them... far less overhead if you don't need the actual pages loaded (which it doesn't appear that you do).

These should be in here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module For the multi-value version (InputfieldPageListSelectMultiple) it looks like I don't have those translatable in the master branch, but they are in the dev branch. When you upgrade to 2.3 (or use the current dev branch), you'll want to translate these two files (via the Language Support translation capability): /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module

Nice job. So far I can't think of any major pitfalls other than with Page reference fields. That is one fieldtype that has a parent_id property (or at least it can). But I don't see this as a major problem, as it would just require the person going in and double checking that it's pointed to the right place after the field is updated. Either that, or the module could be configured to disregard that particular property. We have this same issue with Form Builder export/import from site-to-site when a form contains Page reference fields. It's not been a problem--so long as you know there may be some loss of translation there, it's easy to correct. So overall I think the approach you are taking here seems like a good one.

Why is it called TinyMCE anyway? BigMCE or GiantMCE seems more appropriate?

You could also change the label with Language Support.

I've really been enjoying this module. This is a must-have development tool.

Thanks for your updates. This module has been updated with your changes, so it now supports drag-n-drop positioning. While I was in there, I added reverse geocoding (generating an address from the marker position), live geocoding of the address changes (previously it required a submit) and a toggle checkbox to enable/disable geocoding.

One other interesting thing I noticed is that we've risen a lot on Google for the term "Open Source CMS". Looks like we are now on page #2 of the results (which is a major improvement), right below SilverStripe and Symphony, but above Umbraco. Then again, Google changes these things up a lot, so your results may vary.

Sure, I'll be glad to share any numbers I have access to. Here's a graph showing traffic growth since the project started. Currently we get 500-1000 visits a day, depending on the day. We may be quite small in terms of traffic still, but our trend is upward. Other than WordPress, it appears that most other well-known CMSs are trending downward in terms of search volume.

Are these two different questions? The answer is the same for both though. You can populate a select box (or checkboxes, radios or asmSelect) from page titles just like you can with Page fields in ProcessWire. In Form Builder, you just select the "page" input type when creating a field. Like in PW fields, it'll ask you for the parent/template/etc., that you want to pull pages from as your selectable options. Unlike ProcessWire fields, in Form Builder you can also have selectable fields that aren't connected to pages.

Good idea. What's the best way to do that? Of course, I can always change the order of them in the markup and that would probably solve it as well.

WireArray types may be associative and are designed to support direct access via indexes. So you could have a collision with a WireArray that has a index of "count" (or one of the other suggested direct access properties). While it's certainly feasible to support that for numerically indexed WireArrays, I'm reluctant to introduce conventions that can't stay consistent across WireArrays.

Thanks for posting this. I've thought a few times that we should have a five-start type voting module at some point and this looks like a good start on that. One thing I want to mention is that you might want to add validation for your $input->post->rating, because it looks like it should be limited to 1-5 and it appears that someone could manipulate the post variable to have any number in it, whether "-500" or "99999", etc. So I'd suggest adding some validation, perhaps something like this: $r = (int) $input->post->rating; if($r > 0 && $r <= 5) $new_rating = $page->vote_score + $r; else $new_rating = $page->vote_score;

Here's an example of a site with [some] subscriber-only content that's running on ProcessWire: http://www.di.net/ Example of subscriber article: http://www.di.net/ar...king_long_view/ Nice job to the guys that made it! (was not me)

Nice job yesjoar. I am always adding template/page classes to my body tag manually and think it's always helpful when it comes to targeting stuff with CSS, especially in specific cases. So this module seems like a good idea. I also like the thinking behind the browser identification, though should mention this would not be compatible with page caching. Many (most?) sites don't need page caching, so not an issue for most I'm guessing, but just something to mention.

That's correct, when you add new permissions (via Admin > Access > Permissions) you are adding it for your own use so that you could check if a user has it. You would edit any user roles that you want to have the permission and check the box so they have the permission. Then in your template code, you would check if the current user has that permission via a check like in Diogo's example. You can also just specify the permission name, which is more common to do: if($user->hasPermission('spam-nico')) { for($n=0; $n<999; $n++) mail('hi@nico.is', 'Hi Nico!', 'Would you like some spam?'); }