ryan

I was actually thinking of adding a "Tools" menu to ProcessWire admin (in addition to Pages, Setup, Modules, Access). The reason for it is that we've now got a lot of tools that don't necessarily fit the definition of "Setup", so thought it might be handy to come bundled with another place like that. PW1 had such a Tools menu like this.

Don't give me too much credit guys. I've got all of 15 minutes invested in this particular module, and most of that was writing the instructions. But the subject came up on another thread and just wanted to have a proof-of-concept of how simple it is to plugin your own hooks to customize user access in any way you want.

Thanks Mike! Great addition -- I will update the profile to make this change. One thing I wanted to mention about this blog profile. I know that you are evaluating ProcessWire among other CMSs, and wanted to highlight that the Blog profile might not necessarily be the best single place to evaluate ProcessWire from. It's just one application/template approach among many that people use. I think that the Basic profile included with ProcessWire actually does a better job of revealing the inherent simplicity, and path-of-least-resistance, of the template system. Whereas the Blog profile gets into using ProcessWire in a more MVC front-end framework approach. So it was intended not just as a blog profile for people to use, but also as a next-step (from the basic profile) demonstration of a more advanced approach. This is a great approach to use, but I usually get people started with the basic profile before exploring this, and other approaches. I'm guessing you probably know all of this already. But even if this is old news to you, I figured I should also mention this for others that may be reading about the blog profile.

PW 2.3 protects file-based assets to unpublished or non-public pages, so this won't be a concern much longer. Matching up names is just one way to do it. I just put together a quick module that provides another way you could do it even more easily:

Assign edit access to individual users on a per-page basis The user must already have page-edit permission on one of their roles in order to get edit access to assigned pages. Otherwise, they will only gain view access. This module is fully functional as-is, but intended as a proof-of-concept for those wanting to go further with adding custom edit and/or view access. The main functionality in this module consists of only a few lines of code, so it should be a simple edit for anyone wanting to take it further. If you make some useful additions to it, please post them. How to use Create a new role called "editor" (or whatever you want to call it) and give the role "page-edit" permission. If you already have a role in place that you want to use, that is fine too. Under "Access > Users" locate the user you want to assign edit access to. Edit this user. For this user's "Roles" field: choose the new role you added, "editor" (or whatever you called it). For this user's "Editable Pages" field: select one or more pages you want them to be able to edit. Save the user and you are done. To test, login as the user you edited to confirm it works how you expect. http://modules.processwire.com/modules/page-edit-per-user/ https://github.com/ryancramerdesign/PageEditPerUser

Antti coded the HTML5 upload capability and may be able to speak to it better than me, but I don't think we have control over that particular order?

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.