ryan

While ProcessWire is more than a CMS, I still think CMS is the best way to market it. That's what our target market is searching for. And just because the term means different things to different people, ProcessWire still fits the actual meaning quite well: "content management system." CMF is perhaps an even better term to describe ProcessWire, but nobody is looking for that. We are #1 in Google for the term "Open Source CMF", and our analytics don't prove this to be a term that anyone is looking for. Whereas, "Open Source CMS" is a rather competitive term (and we usually appear somewhere on page 2 of the search results). Even though we are more than a CMS the way most people know it, I still think it's the term that connects with the broadest audience. People looking for a CMS find a great one with ProcessWire. And when they are ready to do more, they'll find ProcessWire to be a tool they can continue to grow with.

Strange I wonder what was blocking it from coming out of the trash. If it wasn't the family settings, I really don't know what it could be. But if you find it turns up again, let me know. Btw, when you said PDA, I thought you were talking about an old school mobile device or something.

Good idea Wanze. This would also have the benefit of excluding most crawlers from the counter. Though if a user really wanted to, they could manipulate the results, but of course they could do that either way. One question, which I'm sure has an obvious answer, but I don't know it. Would the $.post request hold up the page render, or would it occur behind the scenes?Basically I'm just wondering if the $.post should be done in a $(document).ready() rather than inline?

I'm looking for a Google Maps expert to work with on a maps project that would be built in ProcessWire. Most likely we'd use FieldtypeMapMarker. The coordinate data set currently consistents of a few hundred entries, though would grow over time. Each item in the data set has various meta data that we would just store with ProcessWire fields. I've built several of these types of things before, except that this one technically goes further with Google Maps than I know about. Some examples of needed functionality: When the user zooms out, large groups of markers need to condense to some other representation, like a single marker with a number in it (or similar). We would need a sidebar of categories and subcategories. The user can click any one of them to enable/disable the relevant markers in the map. The map would need to have a full screen option (like with a YouTube video). The map must be mobile friendly for those on cell phones, etc. If you have this type of expertise with Google Maps, please PM me. This would of course be paid work. I will share the full scope of the project with anyone interested and I would be looking to get an estimate from you. This project would move quickly and need to launch within a month from now.

Thanks again for making this. I have added it in the middle of the API navigation.

This is true. It's not currently possible. I understand there are some good use cases for supporting one level of repeaters within repeaters, so I'll be on the lookout for a way to support it. But for now, the best route to take for the use case you mentioned is to do it with pages instead of repeaters. Though in your case, I think the textarea option might be a good one since you only need a key and value. You could enter the variants like this: 5.99=Half order 6.50=Half order with cheese 9.50=Full order with cheese On your front-end, you could work with it like this: $variations = array(); foreach(explode("\n", $item->variations) as $line) { list($price, $label) = explode("=", trim($line)); // you could output the variations right here echo "<li>$label: $price</li>"; // or you could stuff them into an array for later use, like this: $variations[$label] = $price; } // how you might output the array, if preferred echo "<table>"; foreach($variations as $label => $price) { echo "<tr><td>$label</td><td>$price</td></tr>"; } echo "</table>";

In ProcessWire 2.3, The $config->userAuthHashType is only used as a fallback if bcrypt/blowfish isn't available. Anthony Ferrara's password_compat library is great btw. We are using portions of it in the current Password class. We may switch to using it in full once we're fully transitioned to PHP 5.3. He's one of those guys that the PHP community is very lucky to have. Brilliant coder, but also has the heart of the teacher and the ability to communicate complex things in a way anyone can understand (especially with his videos).

ProCache completely bypasses ProcessWire, so any code that saves a counter would not get executed. As a result, you probably don't want to cache pages (whether with ProCache or the built-in cache) that you need to execute the counter code on. This is one reason why using separate services or software for analytics is a good thing (Google Analytics, Piwik, etc.)

I love the name Soma. Great idea. Seems like we should link or mirror this like we're doing with the cheatsheet. Since I regularly add new hooks, how is it best kept up-to-date?

VHS vs. Beta, BlueRay vs. HD-DVD, etc. -- These are winner-takes-all markets. The CMS market is a totally different landscape. But I agree with the premise of marketing and the importance of getting the word out there. I also agree that we can learn things from the marketing of other related products out there. Though word-of-mouth is the best marketing there is, so I agree with Kunane that making the product (and support) the best it can be are great ways foster good word-of-mouth. ProcessWire is a community project rather than a business, so we don't have the marketing resources of for-profit businesses. But as we grow I think we'll have more and more resources to pursue new avenues of communication.

Thanks guys, looks like I broke that over the weekend, but the fix was easy. Now fixed.

I'm not familiar with the internals of the ProcessDateArchiver module, but is the page in question (or its parent, or its target parent) using a template that is related to the ProcessDateArchiver module?

In cases where a drag-drop isn't supported (like on a cellphone, tablet, etc.) you would edit the page, click to the "settings" tab, and change the parent from there. If it still doesn't let you put it where you want to, you may need to adjust the family settings of the relevant templates. Those family settings in each template optionally control where pages will be allowed to ultimately live or be moved to.

The "501 Method Not Implemented" concerns me a bit, as that sounds like maybe the server has some firewall, mod_security, or something specifically blocking file uploads. But before we look more at that, I would double check that your /site/assets/files/ really is writable. 755 permission isn't something that's going to work on every server. Also, when you transfer a file from dev to production, it's possible those permissions are lost, or are not consistent with the permission needs of the server. You might want to try installing a fresh copy of ProcessWire (dev branch) on the server in a subdirectory. When it reaches the "file permissions" section (same screen as DB config), see what it recommends as a starting point. You may ultimately have to adjust the permissions of the files that are in /site/assets/. Some FTP clients may provide the option to do this for you, in one shot. If you have SSH access, you can also do it easily with "chmod -R ...".

Are you actually trying to connect to MT's MySQL server from outside of MT's network? I'm guessing they don't allow outside connections to their MySQL servers. Actually, I'm almost sure of it, as I've tried before (though it was while ago).

You might need to switch to the dev branch to take advantage of that fix. In the field settings "details" tab, you'd set the API value to be "Single Page or NullPage" or "Single Page or boolean false", depending on what you prefer. Note that the autocomplete is built as a multi-page input, so it may still behave as such on the admin side.

Added to the wiki. Though not exactly sure how to categorize it… but we'll figure it out eventually.

Sounds good, makes sense to me. I will put in a todo in MarkupCache to support the serialize/unserialize where appropriate.

Making ImageSizer::resize hookable seems like it's a good idea for this need. I will go ahead and make it a hookable method and should appear in the dev branch after I test a bit.

I don't build a lot of multi-language sites, so some others here may have better suggestions than me. But in your case I would probably build separate trees for each language. Then have some code at the top of your shared template file that sets the language consistent with the branch: if($page->rootParent->name == 'en') $user->language = $languages->get('en'); else if($page->rootParent->name == 'es') $user->language = $languages->get('es'); else if($page->rootParent->name == 'fr') $user->language = $languages->get('fr'); or better yet, if we can assume your language names and rootParent names will be the same, you could do this: $language = $languages->get($page->rootParent->name); if($language->id) $user->language = $language; For your categories, you would want to use a Page reference field. Add a text field to the category template that uses the TextLanguage field type. (You'll have to install the LanguageSupportFields module for this). Then every time you add a category, you'll have inputs for each of your languages. When the front-end of your site outputs this field, it'll pull from the correct language automatically.

While Soma is right that the only way to get 100% before and after everything that happens is to literally put it in index.php, there are a couple of hooks that may provide what you need. An autoload module's init() function is a good starting point, and ProcessPageView::finished is a good hook to end with.

Actually I think you've got a fine solution here. Part of the reason that repeaters are built on top of the pages system is so that they could be accessible in a manner like this. So while it is relying on internals of the repeater fieldtype, these particular internals are meant to be exposed when you need them. Repeaters are pages so that they can benefit from that accessibility. The only thing that might need to be added to the selector is an "include=all" or better yet, "check_access=0", since those repeater items are technically access protected.

Horst, that's a good suggestion. I have gone ahead and added this additional check. I guess the thought was that if there was going to be a fail, it would have happened before it reached this point. But that's not a good assumption to make, so I think your suggestion definitely makes sense.

The parent_id and template_id are one way to go, but you could instead use 'findPagesSelector'. You can set this to a Field object, or you can set it to an InputfieldPageAutocomplete instance, like this: $f = $this->modules->get('InputfieldPageAutocomplete'); $f->label = 'Exclude in pages'; $f->attr('name', 'exclude_pages'); $f->attr('value', $this->exclude_pages); $selector = "parent_id=1, template!=admin"; foreach($this->exclude_tpls as $name) { $selector .= "|$name"; } // example: parent_id=1, template!=admin|this|that|whatever $f->findPagesSelector = $selector;

In order to get the page being edited, you would want to hook into something like "ProcessPageEdit::execute" and ask it for the page being edited from its getPage() method, i.e. public function init() { $this->addHookAfter('ProcessPageEdit::execute', $this, 'editPage'); } public function editPage(HookEvent $event) { $page = $event->object->getPage(); // $page is the page being edited } Another thing I want to mention is that it looks like you are doing a lot with facebook on every single request. Maybe that is necessary, but if it isn't, you might want to look into only init'ing the facebook stuff when certain conditions are met. I don't know what those conditions would be in your case, but just bringing it up. In such a case, you may find it helpful to move most (or all) of your init() code into a ready() function. That ready() function is called automatically when the being being rendered is known, so you could do things like this: public function ready() { if($this->page->template == 'admin') { // initialize facebook code } }