Leaderboard

ProcessWire Concatenate Fieldtype Fieldtype that concatenates the values from one or more other fields at runtime. The value can contain additional formatting and/or words as needed, which you define in your Concat field settings. Example Problem: Your system has a first_name and last_name field, and you want to have a separate full_name field composed of first_name and last_name, without redundancy. Solution: You would create a new Concat field, click the details tab, and enter "first_name last_name" (the fields you want to concatenate) in the settings. Other Potential Uses Having a field that combines the value of two or more others, without the redundancy of separately stored data. Defining a custom “label field” for select boxes, like those used with the Page field. Defining a custom label for your Page List that includes your own formatting. Defining an alternate variation of a text field that uses a different text formatter. Considerations The value for this fieldtype is generated at runtime and thus no data is stored in the database. This is good because there is no duplication. However, it also means that you cannot directly query a Concat field from $pages->find(), for example. If you happen to change the name of a field being used in a Concat field, you will have to update the name in your Concat field settings as well. By design, Concat fields do not inherit the text formatters of the fields they concatenate. You define these separately with the Concat field. Because this is a runtime-generated field, there is no Inputfield associated with it. How to Install Install the module by placing FieldtypeConcat.module in /site/modules/. Check for new modules on the Modules screen in the ProcessWire admin. Click Install for the Concat Fieldtype. How to Create a Concat Field Under Setup and Fields create a new field using type Concat. After entering the new field name and label, click Save. Click the Details tab and enter one or more field names. Separate them with whatever spacing and punctuation is appropriate. Optionally choose one or more Text Formatters. If you are not sure which, “HTML Entity Encoder” is a good default to use. Save. Add your new field to one or more Templates. How to access the value of a Concat field This is no different than accessing the value of any other field. If your Concat field has the name “full_name” then you would output its value like this: echo $page->full_name; Download PW Modules Site: http://modules.proce...eldtype-concat/ GitHub: https://github.com/r...FieldtypeConcat

Still another 8 hours here in Holland but best wishes for 2013 to everyone here!

The ProcessWire 2.3 installer now lets you set the admin URL as part of the install process.

Nice! I've updated TinyMCE in the InputfieldTinyMCE module to version 3.5.8 and everything seems to work at first sight. Did some limited testing on Chrome OS-X with inserting images, links and basic styling.

Turns out that this was going to add more complexity than I was comfortable with for this field configuration. For instance, you've got an asmSelect and can select fields, but that only says what fields and order. It doesn't say what punctuation or other words you might want in there. For example, if I wanted to have my label composed of fields "first_name last_name" then I'd just want a space separating the two fields. But if I wanted it as "last_name, first_name" then I'd want a comma and a space separating the fields. Furthermore, lets say I wanted "last_name, first_name, Age: years_old". So it seems like more is needed than just the ability to select multiple fields. As a result, I made the FieldtypeConcat module instead, which takes care of all these needs and more. I had the subject of this thread in mind when creating the module, but there are plenty of other situations where this module may be worthwhile.

Just updated these formatters for textile v2.5.1 which was released about an hour ago. HNY!

First day of the year here in "old" England. Spent it rigging up a little dev server with Ubunto, Webmin/VIrtualmin and Samba and then trying to work out why it doesn't work. Oh, joy..... PS: Now I am just going to set up a couple of PW thingies as Server Templates for quick developinginging... Joss HNY - (Abbreviated to help those infested with spyware...)

This should now be fixed on dev.

I agree those will also be useful down the road. Though from this side, those are a little harder to break, so the more immediate need is a test suite for selectors. This is also needed to maintain consistency between selectors that result in DB queries, vs. selectors that occur in-memory. Because they are handled by two totally different things, this is a common point of inconsistency. They aren't even 100% consistent right now, but I'd like to aim for it, and tests are necessary prerequisite for this. Thanks! I'm not particularly experienced in this area either. But I think our needs for a test suite are different than those of traditional TDD. We need something like what you and I were originally working with, but taken a lot further. It needs to be a site profile built for the needs of running these tests. It would contain a diverse range of pages and fields, and the template file(s) would perform the tests, looking or anything unexpected. One thought is that we might build it on top of the existing skyscrapers profile since that already contains a good number of pages and fields, along with intelligible test cases to work with.

Exceptions are catchable, not hookable. I could probably add a hook to manually trigger in PW's main exception handler. Though if a DB exception occurs at bootstrap time (which is when you'd likely see it, if it occurred), then any modules wouldn't yet be loaded. This would also introduce the potential of infinite loops, like if any of the hooked functions themselves triggered an exception. It would be more likely to occur in this case (the last resort exception handler) since an exception at this point is a fatal error and means something about the system isn't working.

Yeah, but that will also make you like Yoda sound - "if inactive is user status"

You can do it if using Inputfields from the API, but not from Setup > Fields > some_checkbox_field. Though I'm not sure what you mean about a double negative. ProcessWire is designed to be friendly to schema changes. We assume that you are probably not defining everything you need ahead of time. As a result, it's preferable to use a checked checkbox field to alter a default behavior, not to enforce one. Lets say you have hundreds of pages using some template, and you decide to add a new checkbox field called enable_nav that you use to determine whether or not to show navigation on a page. You could say that you wanted that checkbox to be checked by default... great, but that only applies to pages created from this point forward. All your existing pages didn't have the field before, and are not checked. So now you have a new problem. Now consider the the alternative, which would be to make your checkbox do the opposite. Instead of calling it enable_nav, you call it disable_nav. Add it to your template, and your existing pages are kept in the proper default state. New pages created from this point forward will check a box to bypass a default state rather than enable one. Using this strategy scales well, enforces consistency and don't break existing systems when you add a new field.

ProcessWire's selector operators *= and ~= rely on fulltext indexes, and I consider these crucial, which why ProcessWire is build around MySQL (MyISAM). Otherwise we'd be using MySQL INNODB and supporting other databases. The only other databases that one comes across regularly in commercial hosting environments are PostgreSQL and SQLite, neither of which support fulltext indexing, last I checked. So it's not a matter of wanting to support other databases, so much as it is a matter of what we need to do isn't easily done on other databases we're likely to encounter. Don't forget ProcessWire is a public open-source CMS, so it's what we're already doing and will continue doing. I stay in business by building sites for my clients with the CMS and they mostly don't know or care about the CMF aspect. But as a web designer/developer, the CMF aspect is the one that impacts my building and maintenance work the most. And it impacts my clients bottom line because it costs a whole lot less to build something complex in PW than it does another CMS (at least those I've used). I'm too impatient and don't think I could be a functioning web developer if I had to build sites around tools like Drupal, WordPress or even EE (and Joomla not even a consideration). There's a lot to like about some of those tools, but just glad I don't have to use them for building new sites. On the other hand, I've always been intrigued by Textpattern, its tag language and of course Textile which came from it. While I've not developed a full site in it yet, I can tell that it's got some real intelligence behind it and it feels a lot more cohesive to me than the other big platforms. That's why I'm enthusiastic even about the idea of it with a ProcessWire framework behind it and would see it as a mutual benefit to both projects. While I think them adopting ProcessWire for their backend is unlikely (given what they've already invested), I think there's still much we can learn from Textpattern. The fact that we've had so many Textpattern users take a strong interest in ProcessWire has likewise made me interested in the Textpattern project.

I've always held Textpattern in high regard, so it makes my day just to hear that the developer thinks the idea has merit. I wouldn't expect them to pursue the idea, especially given the time they've already invested. There are probably larger considerations than it appears on the surface, especially for someone that authors a CMS. I also don't think it solves everything they are trying to do. For instance, PW already has a strong hook system in place, whereas their need is to support an existing one and maintain compatibility with it. Their list also indicated one of the goals as database independence, and PW is dependent on MySQL and certain aspects like indexes (fulltext indexes for example, which are far from universal). On the other hand, I do think PW as a framework would solve MOST of the things they are wanting to do, just not all of them. But that's only a surface evaluation and there may be much more to it when considered in the context of the TXP system, history, requirements, code as a whole. That's not something that I think any of us can evaluate. And especially not me, since I don't have much experience with TXP. But I think the best thing I can do is just express support and enthusiasm for the idea should it ever become a consideration. Lots of respect to Textpattern as a long running quality platform and group of folks that knows how to build a great CMS.