ryan

Great site! The design really compliments the nautical/sailing photography quite nicely. It makes me want to go sailing. I wish I could… But we have no big lakes, rivers, or any large bodies of water in Atlanta… well except for in my basement when it rains.

Sorry if this is a dumb question. But are you using a browser that supports the HTML5 "number" input type? Does the issue only occur when you choose "number", or does it have issues saving when "text" is selected as well?

I think that traditional version control with Git or the equivalent is great for template files, front-end development files and your own custom modules. When it comes to defining the templates and fields on the admin side, it's better to do this from the admin rather than migrating SQL queries or the like. So someone in your team should be the gatekeeper for these administration resources.

I'm not surprised that the profile exporter module doesn't work with multi language fields just because it was written before multi language fields existed. Though it's not totally clear to me why it wouldn't work, since the multi-language values become part of the regular field data. I'll have to experiment with it and update the profile exporter module to support them. When you imported the profile, did it show the Languages module as arleady installed, or did you have to install it after importing the module?

I think this happens because the code that removes the fields from templates doesn't know anything about specific fieldtypes. In that respect, it's different than a delete action. I'll think on this some more and see if there's an alternate way.

When I'm installing to a new server where I'm not totally sure about the capabilities of it, I install a fresh/new copy of PW just to test and see if the installer complains about anything. That doesn't mean you have to use that fresh copy for the actual site, but it does give you a picture of potential issues that might need to be addressed on the server side. Based on the error message you got (a missing image) I would guess that not all the files made it over in the transfer, and it might be as simple as just attempting to transfer them again. However, the error you got was a Warning rather than a fatal error, so it shouldn't prevent the site from running. There's always a chance you were getting the same warning on your dev server, but didn't see it because debug mode was off.

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

It doesn't matter. Though if you had multiple "sort=something" statements, then it would consider the order of the sort statements. Meaning, if you had "sort=last_name, sort=first_name" then the results would first be sorted by last_name and then by first_name. Whereas "sort=first_name, sort=last_name" would do the opposite.

Great idea and module Nik! This will actually be quite handy on a site I'm working on right now.

Thanks for letting me know. I'll take a look at this. Though specifying "0" for either dimension means "keep it proportional", and that would take precedence. What were the original and target dimensions of the image you were seeing get upscaled?

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).