ryan

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 } }

That's good to know how Joomla is doing it. Thanks for looking into it. Having to rely on a <base> tag is something I'd want to avoid for ProcessWire (on the front-end), but I'm fine if that's how TinyMCE does it in its own iframe. So I will definitely look into document_base_url setting to see what we can learn from it. No doubt we'll still have to do some kind of replacement tactic. But if we can reduce the number of places we need to do it, that's a good thing.

You don't need to change it of course, but I just was confused by the label so wanted to mention it. I was getting the profiles mixed up. I thought the one you posted was an upgrade to the last, but now I see it's something different. Might be good to see this one on modules.processwire.com too, because I think your new one is more in line with what people look for in site profiles. Though both are obviously useful for different reasons.

Does it swap in the actual directory at runtime? Meaning, if you click the "HTML" button in TinyMCE, do you see the correct URL rather than the relative one? Ultimately though, if they are storing a directory that is a placeholder it's the same problem in that the content lacks portability. But it at least sounds more portable. Handling directories for files/images is one thing, because the URL has common elements for all of them. But handling URLs to other pages is another matter.

Media Temple isn't still using MySQL 4.1 are they? I thought they finally switched to 5 about a year ago. I had a client there that was using a legacy application that was not MySQL 5 compatible. Media Temple's little "change" broke their entire site. I had to setup a MySQL 4.1 server for them elsewhere just to bring it back.

That syntax was not intentional. I'm glad to hear it works, though I worry if there are any side effects. For example, it seems like $p would still have the original ID of /my-page/.

I'm not up-to-speed enough on Google Maps to be able to troubleshoot very well. But if it stopped working on its own without there being some change somewhere, then it's got to be related to a change at Google Maps? Still, you might want to put a console.log(poi_id) and console.log(poicolor) in there to monitor and isolate what's going on. It would be nice to know specifically where the info is getting lost.