ryan

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.

Okay I think I understand what you are saying. So you want to just load a fresh copy from the database, not keep an existing copy at some state in memory. Do this to load a fresh copy from the database: wire('pages')->uncacheAll(); $oldPage = wire('pages')->get($page->id);

DaveP, can you try this from your template: var_dump($page->field); Replacing 'field' with the name of that field. See what it tells you. Since this is a textarea field, check what Text formatters are applied to it on the 'details' tab of your field settings. Try removing any temporarily and testing again (just don't forget to add them back). Let us know what you find.

Can you double check that you have the LanguageSupportFields module installed? Also, I did fix a related issue a couple weeks ago, just in case you are running on an older version. Just tested here with a simple textarea field and is working. I created "summary" and "summary_se". It's identifying "summary_se" with the label "Swedish" above it. Let me know if you still can't get it working after double checking the items above. I'll need to know which fieldtype you are using so that I can duplicate a test here as closely as possible.

ProcessWire keeps a memory cache of pages loaded, so when you retrieve a page, its going to be the same instance of that page when you retrieve it elsewhere. But once you save a page (in the API) that memory cache gets cleared. If you wanted to keep an in-memory copy of it before it was saved, you'd want to clone it sometime before the page is saved: $pageCopy = clone $page; From that point forward, any changes to $page won't be seen in $pageCopy. This clone will cease to exist once it is out of memory scope. For obvious reasons, file-based assets aren't cloned here. So if your clone depends on file/image assets, then you have to create a new page not just in memory, but on database/disk too. Here's how you do that: $pageCopy = $pages->clone($page); That does a recursive clone, cloning not just that page, but any children too. See the parameters to the $pages->clone() function for additional options to control this. You can also specify that you want it to clone to a different parent. Be careful with the cloning as it's something you probably don't want to do on every page save. It can be an expensive operation if there are lots of files or subpages associated with the cloned page.

I had to try it on another installation, but was finally able to duplicate the autopopulating date issue. It turned out to be a rather complex thing, took me a couple hours to figure out. But I did figure it out, and committed it yesterday. I also fixed the issue Wes mentioned with the access in a file/image field. There were more considerations with file/image fields. The fact that they get submitted by ajax is rather confusing for the repeater. So if you added a new item, uploaded an image, then entered a description or sorted it, then description or sort would be lost. This issue has been fixed. I think this might be related to the issues mentioned above that were fixed yesterday. I just tried to duplicate here and couldn't, so am hoping I got this one fixed. Though if you could double check that it fixed it there too, that'd be great. Sorry I missed this before, thanks for letting me know. This doesn't sound good. I will definitely avoid cloning any pages with repeaters on them until I can get into this one. I will try to fix asap, hopefully early next week.

Good points. Lots more cleverness to add to the Modules page for sure, including the solution you've already implemented with collapsing the module sections. Just not ready to jump into that pool just yet (battling time and work), but figure small improvements are worthwhile till then. We'll plan to get some nice upgrades with the Modules section in 2.3.