ryan

I thought that the MODX move was interesting too (as were the EE changes a few months earlier). I don't think it affects anything about ProcessWire, other than that it seems to drive more users here. We won't be following the path of MODX, in case anyone was worried. We get paid by the sites and apps that we develop with ProcessWire, and by the commercial support of modules like FormBuilder and ProCache. I don't have any inside knowledge on the changes at MODX, and may not understand the full scope of them, but here's my outsider opinion about it… I can understand why it is shocking to folks that use MODX, because it kind of destroys the perception of MODX as being a big and stable player. In my mind, they were a big and successful company, and I think that was a lot of other people's perception too. Why would they ever have to rely on a little hosting company with a toilet name and an HTML5 logo? MODX is way above this, or so I thought. The changes instead reveal reality that's probably always been there… MODX is a labor of love rather than profit, as most open source projects are (including us). But MODX has grown big enough in user base that keeping the whole ship afloat means having a team people that dedicate lots of time to it. These people have to be paid in order to take care of their own families, etc. So it looks to me like they are just making the tough decisions necessary to keep the team together and stable. It's not pretty (especially the Siphon part), but digging up the floor to fix the plumbing never is. WordPress has proven that hosting is a safe and viable business model to sustain a big open source project. Supporting other CMSs on the Siphon platform is probably just about risk reduction (put the eggs in a few different baskets… err, siphons… rather than all in one) and it would probably make a lot more than it would cost. None of us should view CMSs as religions. I'm glad that I can run Windows apps on my Mac now, when I need to; that doesn't make me prefer Windows. I'm not sure that having web hosting that can only run MODX would be worthwhile. The value proposition with WordPress hosting (which can only run WordPress) is entirely different. Most people using MODX (and ProcessWire) are professionals that have multiple tools. Most people using WordPress are consumers that know how to write, but don't know anything about web development. Given the different audience, I don't think MODX could duplicate WordPress's hosting success by only hosting one product. But I do think they can be successful by catering to the needs of the audience, which is rarely glued to a single product. If diversifying the eggs among multiple baskets helps to drive development for MODX, then that can only be a good thing. Hopefully that's their intention. If their reality really is as it sounded, then the changes were probably good, even if shocking. I think the fear that people might have is that this is somehow driven by investors trying to monetize the software for themselves. But that just doesn't seem to add up in this case. Instead it presents a lack of sustainability in their existing system that had to be fixed (which is itself shocking). I'm just surprised that: 1) They aren't as big and successful as I thought; 2) They don't have a stronger source of income; 3) Any of this was necessary; and: 4) They told us. I don't think that folks should abandon MODX because of the changes. Their team has put themselves in a vulnerable spot and we should support them. While I don't totally understand their changes, it seems like they are doing this to find sustainability more than anything else. While I support and wish the best for MODX in their changes, I also want to be clear that we will not be following that path. We're already on a beautifully sustainable path here, thanks to all of you.

Sorry to hear about the job loss, but you'll appreciate it later on as you move on to bigger and better things. I think it's good that you've invested time in learning ProcessWire. You know how to use a tool that most people don't, and a tool that lets you easily turn any idea into reality. It will be a money printing machine if you want it to be. Unless you have a lot of bills to pay, don't jump back into something where you are dependent upon another employer for your livelihood. You can make a lot more money working for yourself than someone else, though it does take time to get there. Be useful. But find a way to be useful to millions of people rather than just your boss. One idea is to find a fairly specific subject you are passionate about and think about how you might build an online empire around it over time. But that's just scratching the surface. If necessity dictates going back into another job, then at least save your best energy (early in the morning or late at night) building something for your own future, rather than just your employer. The internet really is the land of opportunity where anything is possible. We have more opportunities than anyone has in history. The more you can make investments in and for yourself and the future, the better.

if($m->viewable()){ A viewable() check shouldn't be necessary unless your selector had an "include=all" or "check_access=0" in it (which it doesn't).

Thanks for reporting back on this. Glad to hear you resolved it.

I like and support code standards, especially the PSR ones. PSR-0 and PSR-1 affect the external use of your code, and provide consistency in how people access your code from the outside. I think these are important standards and am very enthusiastic about them for the most part. PSR-2 is not in the same class. It's a good standard, but is more about internal style than external access. It's one of a few good standards to consider if you are starting something new, especially with a team. But if a project has already adopted a style standard, it would be silly to change from one good style standard to another. The point of standards is unchanging consistency. Changing style standards is counter to the purpose of style standards. I don't think the committee behind PSR-2 would suggest changing from another good style standard to PSR-2. But I do think they would suggest PSR-2 as a solid style standard for new projects, and I would agree. However, PSR-2 is not a clear choice even for new projects. It is somewhat controversial in that it's leaderless committee-design, full of compromises making concessions to differing opinions that don't usually go together. I think the committee-design is apparent in the resulting code style. I'm sure the folks behind it would agree and admit it is a lot of compromise. In this respect, I think it may be weaker than some other style standards, but that's always subjective. However, to focus on how or where it was designed is to ignore the point of the standard. So I very much respect what they were trying to do and have done. I hope that PSR-2 will survive because I think the intentions are good. Though I'm not confident it will be so common 5 years from now. But I think PSR-0 and PSR-1 are here to stay. I hope that folks can understand why it would be a counterproductive (even disrespectful to the purpose of standards) for an established project to change from one internal style standard to another.

Here you are making ProcessWire do the same work twice (not efficient): if(count($page->images->findTag('gallery'))>0) { $gallery = $page->images->findTag('gallery'); Instead, do this (efficient): $gallery = $page->images->findTag('gallery'); if(count($gallery)) { // ...

I think the problem here has to do with the validation/sanitization functions. Most likely the values are coming through as strings (since they come from a user input form) and your code is throwing them out since they don't match is_int(). In FieldtypeForm.module: Make your getBlankValue() function return a blank string (or 0 if you prefer), rather than an array. In sanitizeValue, typecast $value to an integer, like $value=(int)$value; if(!$value) return null; Then get rid of the is_int($value). Values coming through forms may be strings rather than integers, so using is_int() to throw out a value can basically break the whole thing. Change your wakeupValue() and sleepValue() functions to do nothing more than: return (int) $value; In your getInputfield() function, you don't need to set a 'name' attribute, as PW already does this for you. If it still doesn't work after the above changes, review /wire/modules/Fieldtype/FieldtypeInteger.module, as it has identical storage needs as your module.

A few things to check: Check if there is a /site/assets/installed.php file. If there is, delete it. That file would only be present if your installation was copied from another, rather than from a fresh GitHub/zip file. Double check that there is an /install.php file present. If you still get an error, try accessing /install.php directly from your browser.

I agree that we'll want a UTC-based date fieldtype at some point. Though this is the first that it's come up, so I think that most folks (including me) aren't using the Datetime field in situations where timezone matters. Most usage has to do with dates accompanying content that is specific to server time, in the same way that the built-in created/modified timestamps are. But as the use of PW increases for things involving authenticated users and storage of their data, I think there will be demand for something like this.

Mats gets the credit there. The nice thing is that MarkerCluster is nice and easy to work with. Here's some more about it with examples: http://google-maps-utility-library-v3.googlecode.com/svn/trunk/markerclusterer/docs/examples.html

I'm not 100% positive about the safety/stability of this option, which is why its only in advanced mode. It may very well be perfectly safe, but since it's something I never use myself, I didn't think I'd be using/testing it enough to adequately support it. It definitely creates a more abstract picture when it comes to the scope of deleting things, and that's the only area of concern I have with it.

Yes, my title and body fields were multi-language. Though I only had the default (en) language populated. To duplicate the issue, would I populate the title in some other language, make that my $user language, and then perform the search? Just want to make sure I understand the all the factors necessary to reproduce.

Thanks for your work here Horst, it looks great! I look forward to going through in more detail so that I can understand it all and then integrate into the dev branch. It makes sense to have this built-in.

I don't see reference to your date field in the code block, so I'm not totally sure I'm answering right… but you can sort by date by adding this to your selector "sort=date_start" or "sort=-date_start" for reverse. You can also stack sorts, i.e. "sort=date_start, sort=title". With regard to formatting, it doesn't matter unless you need to specify an actual date in your selector string. Should that be the case, you would just want your date to be in a format that is either a unix timestamp, or a string recognized by PHP strtotime(). Meaning, all the following would be valid and equivalent in a selector: date_start>=today date_start>=1365436783 date_start>=2013-04-08 date_start>=4/8/2013 date_start>=8.4.2013 date_start>="April 8, 2013" When a date is coming in via user input (like from a datepicker), I'll usually convert it to a unix timestamp before putting it in the selector. That's because: even though we could stuff the user-input date string into the selector, a unix timestamp (which is an integer) is much simpler and safer to validate as user input. if($input->post->date) { $date = strtotime($input->post->date); if($date) $selector = "date_start>=$date"; }

It would depend on what method of multi-language support you are using. If using LanguageSupportPageNames, you could do this: foreach($languages as $language) { $url = $page->localUrl($language); echo "<a href='$url'>$language->title</a>"; } or this $saved = $user->language; foreach($languages as $language) { $user->language = $language; echo "<a href='$page->url'>$language->title</a>"; } $user->language = $saved;

Unless you prefer separate trees for each language, you might want to consider the new LanguageSupportPageNames module (included with the core), which will let you accomplish that URL structure pretty easily. If you try it out, use the one from the dev branch, which is a little more up-to-date, as this module is in development. To accomplish the structure, you would do this: In Language support, assume that "nl" is your "default" language. So edit the "default" language and change the title to Nederlands or whatever the right spelling is. Add another language and name it "en", with title: "English". Install both the LanguageSupportFields and LanguageSupportPageNames modules (in that order), as they are not automatically installed with LanguageSupport. Though they are included with the core, so all you have to do is click "install". Change title field to be of type "TitleLanguage" and all relevant text fields to use TextareaLanguage or TextLanguage. Edit your homepage and click to "settings" tab. Make the "name" field be blank for Nederlands, and make it "en" for English. Check the box to make English active, if necessary. Save. Edit your About Us page, and again click to the "settings" tab. Make the default page name "over-ons" and the English page name "about-us". Do the same with any other pages. Keep in mind that the "name" field is optional for all pages. When left blank, it will just use the default (nl) name instead. But it should still be able to determine the proper language based on the URL, so long as you've configured the language names at the homepage.

No doubt. But pretty hilarious that they would use the same language that would be used to describe a web request, at least from a systems standpoint.

Doesn't this literally describe a web request?

What version of ProcessWire? (I couldn't tell from the screenshots). What are the steps to reproduce? For instance, after which action did the error start occurring? Thanks, Ryan

If I'm reading it right, it seems to meet both criterion A and B. It is currently required by the system for "transmission of communication". And it is "strictly necessary" in order for the system to function. If I can find a way to make it optional, I will. But for the time being, it is required by the system.

On a file system, you can't have two of the same filename in the same directory. Filenames as keys ensure that same remains true in memory.

Based on the time of your post, I'm guessing you might have hit it when I was pushing updates (at exactly 6 am yesterday). I managed to break it for about 5-10 minutes before realizing it. Let me know if it still doesn't work for you. @nico I'd love to have a look. I need to setup something similar (outlining a route on a gmap) for another project.

I don't often use that syntax, but if trying to make something consume as few characters as possible, it works.

Actually in this case /cities/ is not just about admin organization, it's an important landing page in the site's navigation and breadcrumb trail: http://processwire.com/skyscrapers/cities/ In ProcessWire we really try to push that URLs are structure and should represent actual structure. What makes sense for the site's structure also makes sense for the URLs, because they are one in the same. If there's a strong desire to have actual city pages off the root level, then you can create them off the root level. While I would question whether that's really the best strategy for either side, there's nothing stopping you from doing it. You can always take the URL segments route too, but when URL segments are used as beginning points (foundations of structure) rather than ending points, you always have to question whether it's really what is best for structure and URLs, or whether it's giving preference to short-term style over proper structure.

Never underestimate the importance of word separation. It's the difference in readability between "pen-is-broken" and "penisbroken". Beyond the potential misunderstandings is raw readability both to users and search engines. While I have a readability preference for underscores, my understanding is that hyphens are the best balance when all factors are taken into consideration. Lastly, this may be obvious, but what gets populated in that name box is only an auto-generated suggestion. After populating the title, one can go modify the name as they see fit (which I often do), before saving the page.