ryan

Can you post what you found with how to localize Google Maps? I've not looked into this yet, and just wanted to have a starting point. I'll update the module to support PW 2.2 languages.

This one was easy to get fixed. Once I saw the 500 error page was from Apache and not PW, I knew it had to be something in the htaccess file. I've not had to use the "RewriteBase /" before, but knew there were some situations where it was necessary–glad we found one. Good to hear you are doing a rollout of a new PW site. Be sure to post in the Showcase when you launch. Your module idea sounds like a great one–I'll be glad to help when the time comes, just let me know.

That "can't have children" isn't enforced by the API. That's just enforced in the admin control panel. It's perfectly valid to have a page with children and then change it's template to "can't have children" just to ensure that no more are added. Likewise, you can set it that no new pages using a given template can be created, but that doesn't mean that the existing ones have to be killed off. Glad you got it working. What you probably needed in your selector was "include=all" or "check_access=0" to ensure that it would include pages the user didn't have access to. See the Selectors section at: http://processwire.com/api/cheatsheet As for the Chrome vs Firefox and Safari thing, I have no idea. But Chrome is trying to one-up everyone, I know that.

I have seen that before, though not in ProcessWire. But feasibly it can happen anywhere. It's what happens when MySQL gets abruptly killed when it's writing data or building an index (like if your webhost did an emergency reboot of the server or the process). You need to run a 'REPAIR TABLE field_body;' in a MySQL client. If you've got PhpMyAdmin, just check the box next to that table and click repair.

I actually have no idea what Microsoft's Web Matrix is... I'll Google it. I didn't realize there were any similarities between C5 and PW. I used C5 a year or so ago and thought it was a fun system to test, just not a system I'd want to develop in. A very different approach they've got going there with C5. But I agree about their marketplace is a great model and one that we need to look into more.

The behavior is intentional. Any time a page is saved (whether just a field from it or the whole thing), the modified date is updated. There isn't currently a way to bypass that. Though if there's demand for it, I'm sure we could find a way. I'm going to marinate on the idea a bit to see if there are any simple solutions that I'm not thinking of yet. But one question would be why wouldn't you want the modified date updated? (preference to only show admin modifications?) I'm just wondering about the broader context, to get a sense of the situations where one would want this disabled.

Thanks for testing it out Jasper, glad its come in handy already.

Thanks for the FTP access. I found out what the issue was. Your server needed this part of the .htaccess file uncommented: # RewriteBase / Once I uncommented that (by removing the '#') it started working. Please let me know if you run into any more issues.

I wish that more people could have seen that tweet from SmashingMag. They sent that tweet to 500,000+ people at the same time, and only about 6,000 got through (and I bet it was so slow for those 6k that most gave up). I think we would have had to be on a large scale CDN to accommodate even a quarter of that traffic at once. So while the tweet went out to half a million people, I'm guessing the majority of people that clicked on it got nothing. I appreciate them tweeting about ProcessWire, but just wish we had the resources to accept their nice gesture. Hopefully we can get a more traditional link from them at some point, something that would spread the traffic out beyond the minute-by-minute nature of twitter. I would guess this is a regular problem with any tweet that gets sent by them... 500k+ followers is pretty amazing and they deserve the great reputation. But no traditional web hosting can accommodate that kind of traffic at once (as far as I know).

I took a look at your PHPinfo and it seems to look okay. At first I thought I found something in your configure command with '--disable-json', but then noticed that JSON support is still there, so apparently that's not it. Though I'm not sure I understand that discrepancy. The only other things I noticed were that 32M is pretty low for memory_limit. I would bump that up to at least 64M or 128M. I don't think that's the problem here, but I do think it could be a problem at some point. Though if it's easy enough for you to change, it would be worth a shot. The last thing I noticed was that there are just a whole lot of extras in this PHP install. There are more PHP add-ons in here than I think I've ever seen before, from various caches to other things I'm not familiar with. Doubtful that any of those are the issue, but just an observation that we may come back to if nothing else turns up. I'm not sure what to tell you to try next. But if you would like, I do believe I could figure it out if I could get in through FTP or SSH and do some old fashioned debugging to determine where it's getting caught. If you would like me to do that, just PM me the info needed to get in, and I'll let you know what I find.

In ProcessWire, a Fieldset is technically a type of Field, so the manner in which you edit it is no different than any other field. But what's different is in how you define the scope of the Fieldset. Fieldsets just define a starting and ending point for a group of fields. A fieldset consists of two fields: 'fieldset' and 'fieldset_END', replacing the 'fiieldset' with whatever you named it. Add your starting and ending fieldset fields to a template. Drag the 'fieldset' where you want it to start, and drag the 'fieldset_END' where you want it to end. Then save. The fields between those two will then be grouped in the page editor. Note that tabs work the same way.

Could I get a look at your phpinfo()? Paste this into a file called test.php and then PM me the URL: <?php phpinfo(); One more question, is the installation that's failing installed to the domain root or a subdirectory? If it's in a subdirectory, paste in here what you've got in the .htaccess of the parent (non-PW) directory.

Good idea. We could do this, and I think we definitely will, but it's not as easy as it sounds. On most servers, the file system is not writable to ProcessWire (except for /site/assets/). So the way around that is for ProcessWire to perform the upgrade through a PHP FTP client (and user supplies the login information to ProcessWire). I'm guessing that's not particularly difficult to do FTP through PHP, but I just haven't tried it yet. Extracting ZIP files is also something that's not as universal as I'd like, but we'll make do. When we build this, we'll probably do it with a module. I'm not sure I want ProcessWire to 'phone home' unless the user tells it to, so it could be a module that's not installed by default, but once installed, it will start phoning home to check on version (using LazyCron, like you suggested).

Don't worry about it. Soma was just saying that there's been a lot of demand for this particular feature and it's a good idea. Keep posting and don't worry too much about searching (the search engine isn't great either). If everyone searched for it rather than posting, we might assume there wasn't much demand for this feature. I'm glad to know about the demand for repeatable fields. This is a small community and I'd almost always rather have people post than not. If we start having to keep up with hundreds of messages a day, than that would be different. But for now, when in doubt, post. You've added some good points to this discussion, and there will be a lot of good reference material in the forums for when this feature is in production.

Check that your server actually supports the .htaccess file. Type "alejkfagjkaelgjk" or something at the beginning of it and save. If you don't get a 500 error on your homepage, then your Apache is not configured to use .htaccess–let me know if that's the case, and I'll tell you how to fix. Do you have SSH access to the server? You might want to do this, just in case some permissions were lost in the transfer: chmod -R og+rw /site/assets The ProcessWire installer can identify most potential compatibility problems at a server. It would be good to download a new copy of PW and install it in a subdirectory there, just to see if it finds any issues with the PHP version, htaccess support, missing drivers, etc. You don't actually need to do the installation, you just need to have a look at the first screen where it performs a system check. This will most likely reveal what the issue is.

I didn't realize that you also added a languages API var, sorry for the duplication there. The new $languages API var can also be hooked in many ways, and I'll be glad to add anything to it that would be helpful to you–just let me know. The $languages API var is extended from this class, which is the same one used by users, roles, permissions, etc. This class: /wire/modules/LanguageSupport/Languages.php Extends this class: /wire/core/PagesType.php Each of the languages is actually just Page. If you iterate the $languages API var, you can get all the language pages. There is also $languages->get(...) and $languages->find(...) that function just like the ones from the $pages API var. I'm not sure that I have enough background on your module to answer that. But did want to mention that the new LanguageSupport module adds a template called 'language' that is used by each Language Page. You can add fields to that template like any other. So if you were to utilize the PW 2.2 languages with your own, then I'm guessing you would likely add the fields to that 'language' template that your module needs, and then they would be available in all the languages. Again, I'm not sure if this is the right strategy for your module or not, but just wanted to mention that is one of the ways it can built upon. It is. The $languages API var can be extended like anything else. If you wanted to add new functions to it, then you would just add a hook for a function that isn't already there. i.e. <?php wire('languages')->addHook('languagesNewMethodName', $this, 'thisClassMethodName'); …or… <?php $this->addHook('Languages::newMethodName', $this, 'thisClassMethodName'); I'm happy to modify or add anything necessary to support the needs of your module – just let me know of any way I can collaborate or be of help.

Remaining the /processwire/ page is always a good idea, especially if your client is prone to using insecure passwords with their accounts. When you first rename it, note that you may get a 404 after saving it. That's okay–it's expected since the admin moved. Just navigate back to your new admin location.

Edit your /site/config.php and change the line that has $config->debug = false; to be true. Then you may get something more descriptive than a 500 error. Check that the /.htaccess file is there, and is the correct one for ProcessWire. Very often when migrating a site, it's easy to miss the .htaccess file and end up with one that was previously on the server. This is the first thing I would check. You mentioned that your index page works? Are you seeing the proper homepage for your site? If so, that's good and that would rule out a database issue. Are you able to access /processwire/ ?

Another way you can go is to use page reference fields. Add two new 'Page' reference fields: topnav and footnav. Make them support multiple pages. Don't restrict it to a parent or template. Select 'PageListSelectMultiple' as the Inputfield for them. Save, and add them to your Homepage template. Now edit your homepage. For the 'topnav' field, select all the pages you want as part of your top navigation, and for the 'footnav' field select all the pages that should appear in your footer navigation. Drag to sort them in the order you want. Edit your main markup file (or head/foot includes) and use the following code to output that navigation: <?php foreach($pages->get("/")->topnav as $item) { echo "<li><a href='{$item->url}'>{$item->title}</a></li>"; } …repeat the same for the footer nav, except iterate the footnav (rather than topnav) field. In the sites that I develop, I almost always have the footer nav hard coded in the main markup file (I don't usually need it to be dynamic). For when I need the topnav dynamic, I'm usually sticking to the site's root level structure for the navigation (iterating the non-hidden children of the homepage). You may need all this stuff to be dynamic, in which case there are a lot of options. But I just wanted to mention that you should only make stuff dynamic that needs to be. When stuff can be hard coded in a template file, it consumes fewer resources. So if you stick to a policy of hard coding stuff that changes rarely and doesn't need to be dynamic, then you'll benefit from better performance, use less energy, save more trees, etc.

I just committed an update that adds counts of abandoned and blank translations with each file (when applicable). You'll see this if you pull in the latest commit, and a screenshot is also attached. I was worried about the overhead/slowness of parsing all those files on every page load. However, I went ahead and tested it anyway. I was surprised not to see any apparent slowdown – it seems quite fast. It is doing some heavy lifting, but apparently not the scale of issue that I thought. Maybe that will change once we get lots more files in there, but for the moment it seems to be fine. Let me know if you experience something different. I will probably add a caching mechanism if it becomes slow.

I definitely like the idea, but don't think I could make it scalable from a development standpoint. It's a rather heavyweight process to parse all the files to detect these things. Once we get to having a hundred translation files in there, I don't think everyone would want to wait 20 seconds for it to parse everything every time the language page loads. I may have to take a LazyCron approach with this to let it do the heavy lifting behind the scenes when you aren't looking. I will plan to do this. I may not be able to cover 100% of everything (like getModuleInfo title/summary fields), but will find out as I do it. My favorite Finnish city today is Turku I watched a TV show last night about the big ships they build there at the Aker (STX) shipyard, amazing projects!

Whenever you click 'edit' for a translation file, it identifies any translations that are no longer current at the top. It refers to them as 'Abandoned Translations' because the original English translation has changed. See the attached screenshot for an example of what I mean. It shows that the original field that was previously worded "Hello, how are you doing?", has been changed to "Greetings, how are you doing?". The field has been blanked, and the translation has been moved to become an Abandoned Translation. We can't make guesses about the scope of the change, so the system has to abandon the translation and let the translator decide what to do with it. The translator may decide that the change is insignificant, and they can just copy/paste their abandoned translation back into the field. Or they may decide to delete the abandoned translation and perform an entirely new translation. If new phrases are added that weren't previously there, then they just show up as new/blank fields to be translated. I maybe able to call these out in some way more prominently too.

Darn, I thought you'd found it. And I think you have, but looks like we can't take advantage of it just yet. At least not with that particular option. It sounds like most agree that it's best to provide the option for everything to be translatable, but don't require everything to be translated. That's pretty much the way it's setup now, except that I haven't yet made those other modules translatable... I will plan to do it. I want to mention that PW doesn't actually require any language files to run. The language in the code is assumed to be English, and the phrases that appear in the code are the English translation. Those English translations are hashed (md5) and then serve as the tokens for all other translations. So it's reasonably easy for us to make something translatable, even if there aren't any translations available for it. The English language you see in the Languages list right now is actually just a placeholder for the language already present in the code. But you could make your own English translation (if you wanted to) just by adding files to it. The good news is that it really doesn't make module development more difficult. The essence of it is that you just have to wrap your text phrases in a function call, so that $value = "text"; becomes: $value = $this->_("text"); The Wordpress i18n documentation will be our starting point for the documentation (assuming it's open source, I think it is) and I'll modify it to be ProcessWire specific and call out any differences. Once your module is sending its text through $this->_('text'), if you want to add a translation to another language, you just go to Setup > Languages > [any language] > files > new, and then type in the path to the file. I'm guessing that some module developers will choose to include json translation files of their module, and some won't. For those that do, one would just upload that json file to their target language in PW and the given module would translate.

Looking good Soma! Just made those changed and tested it out. Very cool. A couple things I found: It reported 0 results for me until I selected another template, and then changed it again to select 'Show All'– then it worked. In your find() code in the module, you could replace it with this and it would give the same result but be a little faster/more efficient: $pa = $this->pages->find($selector); $total = $pa->getTotal();

I think direct access is kind of assumed, just because you'll see it in nearly any code example you come across for ProcessWire. But maybe it wouldn't hurt to add it, as it's only 2 short lines (see below). But I'm happy either way. <?php $value = $page->any_field; // same as $page->get('any_field'); $page->any_field = $value; // same as $page->set('any_field', $value);