ryan

Michael, thanks for the description. It should be okay to use multi-language fields in a repeater (at least I have before), but it's been awhile. I will locate whatever the issue is and fix. There is an instance there where both repeater and LanguageSupport hook into the same thing, so could be that I need to add a load priority to that (that's my initial guess anyway). Antti has sent me a site profile to test so I hope to be able to reproduce the non-working language alternate fields and have a fix for that shortly.

Thanks Nikola, I got it working and definitely going to add CodeMagic to the core. The current HTML button is pretty much useless in my opinion, and it's one of those things that causes me trouble almost every day. I wish I'd known about CodeMagic much sooner, this completely solves it. Diogo I'd like to give more lovin’ to TinyMCE, but I lack the expertise and time to do all the things we'd like to do with it in the short term. Though learning about CodeMagic from Nikola just brightened my day a lot. I'm hoping that eventually we'll find others that wants to help with or take over development of the TinyMCE Inputfield in ProcessWire. Taken on it's own, TinyMCE is a bigger and more complex software that ProcessWire itself. Since TinyMCE is 1 Inputfield of many in ProcessWire, I have to be careful not to let it take over too much time from the rest of PW. TinyMCE will gladly take a full day to figure out a very small thing. I'm certain there are others that can do the TinyMCE stuff better than I can. But I'm going to do my best to keep mastering it either way, and put in incremental improvements as we go.

Good idea, I just renamed it to: "ProcessWire Forum: Latest Posts"

I think that I can add the necessary hooks to support this. Overhead with high traffic functions is always a concern with hooks, but did recently figure out a way to do it in a way that avoids any overhead unless/until a hook is actually active. So it should be possible to make something like $db->query() hookable. I will take a closer look at this.

I would avoid making a repeater field global, because then it'll require every template to have that repeater field. I can't say as though I've actually tried it though. I'm not positive it would work. So if you have that need, let me know if you find it doesn't. If you don't populate any fields in a repeater, it's considered unpublished. I have the need on a project right now to keep some repeater items published and some unpublished, so currently thinking about ways to do this. I may have a solution soon.

Awesome work Nikola! Just tested out here and it works great. Really beautiful admin theme and great details. A few questions/comments: How do I get the codemagic plugin to work? I worry a little about having people replace their /wire/Inputfield/InputfieldTinyMCE/ dir because it'll get wiped out whenever they upgrade. Can you think of any ways I can adjust the current TinyMCE setup to support the additions you've made without having to place/replace files in /wire/? Another strategy is that you can just create your own InputfieldTinyMCE_Futura like this: InputfieldTinyMCE_Futura.zip Place it in /site/modules/InputfieldTinyMCE_Futura/ and install from the Modules tab. Then change all your TinyMCE fields in PW to use that one instead, as the two won't work together at the same time. But I think putting in another TinyMCE may not be ideal as a long term solution either, just because there's lots of duplication. So ideally I'd like to find a way to support admin theme authors with more customizability to to our existing InputfieldTinyMCE. If you can let me know all the things you had to change, we may be able to take it from there. I ran into an issue as I scaled down the window that made me think it might just need a min-width set somewhere. This is in Firefox 11. I find the design of this theme really appealing and inviting with great use of color. There are only two things: 1) The search box is always pulling in my eye like a black hole when I'm trying to look at something else, becoming a bit of a distraction, but I can get used to it. 2) Very minor point, but the p.notes fields look very bold with the green background. It looks like they are the most import info in the field, when they are supposed to be the least important. The intention behind the text in those elements is that p.notes are meant to be secondary/small/faded. 3) Another minor one, but I think TinyMCE is a little hard to use when there is no padding between the edge of it and the text that you are typing. I know they bundle it like that, so I'm probably alone in this. Thanks again for your great work with this theme!

I like the way jQuery handles single vs multiple items too, but just not always when translated to PHP and the needs of ProcessWire. There are some language differences between Javascript and PHP, storage differences (in memory vs database), and most importantly big differences between the needs of a CMS vs DOM. Ultimately having PW treat single/multiple the same as jQuery in all areas would make PW more confusing in places where it makes jQuery more simple. But there are times when it makes a lot of sense, like the one you identified here. And there may be others too, so keep an eye out and let me know.

Thanks Netcarver -- I'm thinking I'll make it implement the ConfigurableModule interface and they can specify the doctype with the module's config settings.

I will have to give that a try. But my like of VI/VIM goes well beyond the editor itself. It's the fact that it's available and installed everywhere. I can connect to nearly any server and it's already there.

It sounds like it really is only the column width that varies, and not the actual data. As a result, I think you can accomplish this just by adding an integer field to your repeater and asking the user to enter a number between 1 and 12, indicating the number of grid columns they want the item to fill. It sounds like you are using an HTML/CSS framework that uses "grid_[n]" classes to carry the width, so I would just map that directly to a field. Once you've got it working, you might prefer to map it to a select with predefined values like 1/4th (3), 1/2th (6) and full (12). It'll be easier for the non-developer to understand that 1/4th means "quarter width" as opposed to "3 columns of 12". But I'd get it working the simplest possible way first (integer field), and then optimize it with pre-defined selections once you know it all works. I'm guessing those columns naturally wrap on their own when at the end of a row, so you dont' really have to worry about clearing floats. foreach($page->segments as $segment) { $width = (int) $segment->segment_width; if($width < 3 || $width > 12) $width = 12; echo "<div class='grid_$width'>"; // output your content echo "</div>"; }

I tried creating a new body_se field and made it TinyMCE, and all still worked here (I also created it by cloning the existing 'body' field). So I think I need to take a closer look at your installation. Please email or skype over login info at your convenience.

Thanks for the screenshots. I think it looks good, though I am confused about what the 'default' language is? The field 'body_se' that has the English label 'Body' while the 'body' (default) field that has the label 'Sisalto'. Shouldn't it be body_se that has the label 'Sisalto' and body that has the label 'Body'? Not that it likely matters here, but just wanted to make sure I understood. The screenshots are helpful and gave me ideas on more to try to duplicate locally (TinyMCE in particular). If I can't duplicate locally, it would be good for me to take a closer look at your installation, so I'll let you know what I find after testing locally.

Alan, Diogo may understand better but I'm still confused myself. I think my confusion just stems from that I don't really know what the output is ultimately supposed to do or look like. But I think I have enough context to sort of understand the direction you are going. Assuming, I understand roughly what you are trying to do, my thought is that Repeaters might not be the right way to go here. Repeaters are for repeating an item of the same type. But I get the impression that the items you are talking about vary in some fashion. If the only way in which they need to vary is by user-defined width, then I'm sure it would be fine to give them an integer or selection box to choose a width. But if they need to vary any more than that, whether in input or output, I think you are better off creating a template for each 'type', creating pages for them, and then let them be selected (as Page references). Here's an example I was helping someone with recently. they have this site with really long pages and really long sidebars with various different types of 'blocks'. Some of the blocks are informational, some highlight a magazine article, some highlight a property, and there are a few other types too. Here's a reduced size screenshot that shows four of them (though they are actually used in much larger quantity): While they build a sidebar on a page, each 'block' there is technically a page on it's own as children of /tools/blocks/. There are several different block templates. The ones you see in the screenshot are: block-basic block-magazine block-basic (again) block-property-photo Each block knows how to render itself. So the template file for block-basic looks like this: <div class'block block-basic'> <h3><?=$page->title?></h3> <?=$page->body?> </div> The page reference field is called 'blocks' and it's attached to any pages that need to have various selectable blocks of different types. They are selected like this: And they are output like this: foreach($page->blocks as $block) { echo $block->render(); } Looking at your original post, I am thinking of each of these blocks as being something like each of the "segments" in your description. But let me know if I'm anywhere close, or totally off from helping to answer the question.

For any PageArray, count($pageArray) returns the number if items present now, but $pageArray->getTotal() returns the number of items total without pagination. So if you specified a "limit=n" in your selector when loading the pages, you can always call upon that $pages->getTotal() to tell you how many matched in total. There is also a $pageArray->getStart() method, which tells you the index of the first item. So if you had specified "limit=10" and you were on page2 in the pagination, then getStart() would return 10. I use these two functions to output a summary of results that tells you were you are. So if you wanted a headline that said this: You'd do something like this: $firms = $pages->find('parent=/firms/, num_staff>100, limit=10'); $start = $firms->getStart() + 1; $end = $firms->getStart() + count($firms); $total = $firms->getTotal(); echo "<h1>Firms with more than 100 staff</h1>"; echo "<h2>Showing firms $start - $end of $total</h2>"; foreach($firms as $firm) { echo "<p>{$firm->title} has {$firm->num_staff} staff</p>"; } // output the pagination links echo $firms->renderPager();

Good idea Adam. Currently it actually will work with a PageArray, but only if that PageArray has just 1 item. That's not intentional, but rather a side effect of the function supporting adding a page by ID number. Since the string value of a PageArray with one item is just a number (the Page ID) it ends up adding that one page. So I think it makes a lot of sense for it to work just like import() if you happen to pass in a PageArray... a definite improvement over what it does now. I have updated the source for this and will test it locally for a day or two just to make sure there aren't any unintentional side effects. Though I also want to mention that PW isn't trying to mirror jQuery in how it treats one item vs. multiple items--I always prefer to know if I'm dealing with one item or an array of them. So I shy away from mirroring that behavior of jQuery. Even so, I think it does make sense in PW for the add() method to take on the role of import() when you send in multiple items. Thanks for bringing this up.

Thanks Netcarver, I didn't realize you were involved with Textile. That's good to hear. I'm a fan of Textile, and lately have really preferred it to Markdown and thinking we should add the Textile modules to PW's core modules. The only reason it wasn't in before is because I couldn't get it to work with UTF-8 text a few years ago when I initially included Textile in PW 1.0. I think I must have been working off Dean Allen's original version back then or something. I have upgraded the Textile module to the version from your repo and will track that one from now on.

VIM user here too, since 1994. Tried to get off it many times, but always return. I think I'm stuck with it for life.

Just like you have to assign a role to a user, you also have to assign the role to a template. Only then can those permissions be exercised. So you've got half of the connection (assigning role to user) and now you need to do the other half (assigning role to one or more templates). In order to give you finer control, the template also lets you toggle on/off a few editor related permissions for roles that have page-edit permission.

A pre-made module for this on the admin wouldn't know what field(s) might be referencing the $page, so it would need to locate all the Page fieldtypes, and perform a check on all of them: "field1|field2|field3=$page". I prefer to view these kind of relations on the front-end of my site (where I can give them a known field context), so my template for the pages in the relation will usually have something like this: echo $pages->find("field1=$page")->render(); If the page isn't part of the front-end site, then I'll remove view access from its template. Or if it is part of the front-end, but I don't want to show the relations, then this: if($page->editable()) echo $pages->find("field1=$page")->render(); Though I almost always integrate these relation-revealing pages into the site structure, as it's rare that this information doesn't have some value to the site's users too. This is an example of one that locates all pages referencing it in a field called 'country': http://www.tripsite.com/countries/croatia/

Great info and tests, thanks Netcarver! I'm thinking RTL support should come pretty easily for ProcessWire. One person had asked about Hebrew awhile back, but I didn't know enough at the time to provide a good answer. Now I do. It sounds like you are a VIM user too?

I think that the '=' vs '==' is a common thing everyone runs into in any language that uses that assignment vs. comparison style. (PHP, Javascript, Java, C/C++, etc.). Running into this on occasion just goes with the territory, regardless of how long you've been doing it.

Thanks for your testing here. It's generally a good idea to have some kind of text formatter on your text fields, because otherwise they are unfiltered (could contain HTML, etc.). So I usually add an entities text formatter to fields like a phone number. I would be curious to know if actually adding a text formatter to it (like entities) produces any change. In your code where you are examining the value with var_dump(), is there anything that occurs before it? Or is this at the very top of your template file? Do you have any modules installed in your /site/modules/ dir? Thanks, Ryan

Thanks this is good to know. Based on that, it sounds like we probably don't need to do anything for RTL support on the front end, since we don't get involved with markup generation there. But we probably do need to make some updates on the admin side. I'm going to hold off on this until we have someone that's interested in making a language pack that requires RTL, but looking forward to the opportunity.

Glad you found a cure, but it's still a mystery. Definitely shouldn't need autojoin to work. I am wondering if you rename the field if that changes anything, like renaming it to 'telephone' rather than 'phone'. That would at least tell us if there were any issues in the table name, or if 'phone' is a reserved word somewhere (though it's not in PW). I'm also still curious what you have set for 'Text formatters' in your field 'details' tab? The text formatters only apply to the front-end, where you were getting NULL, so I'm curious if a text formatter was failing and causing the NULL. I did try to duplicate here creating a text field called 'phone' but everything worked normally. It would be great if we could find a way to duplicate it because this is a strange one. Thanks, Ryan

Uhh, yeah new PHP technique, didn't you know? Return early and you don't have to execute any of the code below--very efficient. Leads to faster execution time. Okay in all seriousness, it looks like I put that there for debugging at some point and neglected to remove it. Thank you for finding it. The problem is, I have no idea how long it has been that way, so I'm going to do a little hunting around GitHub to figure it out. If this has been disabled for a long time, I'll need to give it some good testing before committing the fix back. Luckily, this particular module is more of an extra than a necessity, but a good thing to have nevertheless. Thanks again for finding it.