ryan

Since the structure is already there, you probably want to use that structure and you won't need to worry about sort order at all, since the sort order is implicit in the structure. I'll adapt MadeMyDay's good example towards the structure from your screenshot. This may not be exactly what you are trying to achieve, but maybe it's close. But the point I'm trying to get across is just that it's better to use this structure for retrieving pages when your output results need it. It's also more efficient to use the structure rather than issuing separate find() queries to pluck stuff out of it arbitrarily. $issues = $pages->get("/journal/")->children(); foreach($issues as $issue) { echo $issue->title . '<br />'; $articles = $issue->children(); foreach($articles as $article) { echo ' - ' . $article->title . '<br />'; } }

Welcome to the forums CNSKnight. Also wanted to add that the most common way to get to that context is not actually from that drop-down, but from the actual template editor. You can click any field name in your template and it'll pop open a modal window where you can adjust the context.

You can have as much or as little of your site in ProcessWire as you want. ProcessWire will run alongside static HTML sites or sites running in other applications. As for access control, you can define access per-template. So if you want the client only updating the photo gallery page, you would only give them access to edit/create pages using your photo-gallery template.

Okay I think this is fixed now. Please try the latest commit and let me know if this resolves the issue on your end too? Thanks, Ryan

Thanks Soma, I can duplicate this. I will hunt it down.

So far I'm confused on this one. When you import fields, it's not getting involved in anything with access control. Repeater pages are also inaccessible to guest either way. They are only accessible via the page they originate from. What you describe sounds like a bug in there somewhere, but so far I can't consciously connect the result with the identified cause. I'll experiment. If anyone else experiences a similar result please let me know.

Mike, what you are trying to do sounds feasible and interesting. How far along with this are you and do you have any specific questions thus far? I'm not familiar with OpenCart, so would probably need to see your Inputfield code for context with any questions too.

Hani, this looks like a good and well thought out solution. Thanks for posting. I can't think of any immediate issues here, so if it seems to be working well in your case, I think you should be good. The only thing I might suggest is copying it to a separate module in /site/modules/InputfieldPageCustom.module or something like that, so that you have a separate module that can be easily carried through version changes. If you do that, remember to update the class name too. It would also enable you to more easily share the module with others that had a similar need.

Thanks, I will make the same change in the core, replacing the second 'true' param with 'Sanitizer::translate' in the setupNew() function. The translate option was added to the sanitizer pretty recently.

In PW1, you'd double click the trash icon for any file/image and it would toggle them all. I liked this solution because it didn't add any extra furniture to the interface for a feature that most don't need, but it was there and handy for those that did. Another route is to have a module that adds a checkbox at the bottom of the list for those that want it.

Thanks Soma, this is a great explanation and it finally makes sense. I look forward to adding this into the core.

I think it's good to have this sort of functionality coming from a module. After all, all of ProcessWire's language support comes from modules that aren't installed by default. Multi-tree is the recommended way to build a front-end multi language site. The only reason multi language fields exist is because we needed a way to support in the admin while using the same page. It was just bonus that they can be used on the front end too. And perhaps they are revealing themselves to be useful enough on the front-end to warrant taking it further in the future. But multi language fields are very far from being a full solution, as only one field type of dozens supports multi language (FieldtypeTextLanguage, which is inclusive of FieldtypePageTitleLanguage and FieldtypeTextareaLanguage). I also don't want to start modifying and adding overhead to the core for features that aren't needed by everyone. This is what modules were designed for. So even if we do future expansion of multi language fields, I still think this is the role of modules. It's great to see what Mcmorry has done with this module, a lot of good thinking and ideas. If more and more people want to handle languages with fields rather than pages, I'm sure that the options will continue to grow.

Nice job with this module. Thanks for your work here. Looks very well put together and seems to solve the need nicely. Just to make sure I understand the usage correctly: This is meant to be combined with use of FieldtypePageTitleLanguage, FieldtypeTextLanguage and FieldtypeTextareaLanguage? Does this look like the sort of site structure one would create with this module? Basically, a traditional structure, but then with the languages added as root level pages, but with no children: /about/ /about/background/ /about/history/ /contact/ /products/ /product1/ /product2/ /en/ <- language: English /es/ <- language: Spanish /fr/ <- language: French So if I hit the URL: /es/sobre/fondo/ it would know to display /about/background/ (using Spanish fields)? Would I replace all of my $page->url() instances with $page->mlUrl() ? Thanks, Ryan

It's a bug, thanks Soma. Thankfully a simple one to fix, and just committed it. Also pushed the PageFinder updates after running through a lot more tests, so all should be in the live source now.

ProcessWire doesn't have an index for this operation because there's no reason to do a $pages->get('/')->find(); because it's the same as a $pages->find(). The person behind the code of it (me), was smart enough to avoid to unnecessary index, but not smart enough to account for it. So it's still trying to execute the find despite there being no index for home and root-level pages. That's why it's only returning pages that aren't home or rootParents, because it does have indexes for those. I've just updated it to redirect a $pages->get('/')->find to just a $pages->find, so will commit that update shortly. Thanks for finding this.

1. That behavior is only useful when doing something like $page->get("headline|title"); where you'd like the headline, but will settle for the title if there's no headline. Literally saying I'll take headline OR title, but I prefer headline." That behavior works there because we're not talking about retrieving pages, we're just talking about retrieving the first non-empty value. Order matters here because we're stating a preference for headline since it is mentioned first. 2. When you use OR "|" in a selector to retrieve pages, you can use "|" between field names, like "title|body*=something". That literally translates to "Find all pages that have the word 'something' in either the title OR body. Order here means nothing, because if it matches in either title or body, you are going to get the page in the results either way. It may match the word 'something' in the title field on some pages, and in the body field on others. 3. You can also use OR "|" in the selector value, like "body*=this|that". That translates to "Find all pages that have the word 'this' OR 'that' in the body field. Some of the returned pages will match 'this' and some will match 'that'. It doesn't matter what the order is either (I'm not sure how it could). Getting back to this: "modified_users_id|created_users_id=1020" -- that translates to exactly the same thing as #2 above, as it should. Literally meaning "Find all pages that were either modified OR created by user 123". When I execute that find on my machine, here is what I get: page: 1, created_user_id: 1020, modified_user_id: 2 page: 4459, created_user_id: 1020, modified_user_id: 41 page: 4601, created_user_id: 41, modified_user_id: 1020 page: 4602, created_user_id: 1020, modified_user_id: 1020 page: 4615, created_user_id: 1020, modified_user_id: 41 page: 6674, created_user_id: 1020, modified_user_id: 40 page: 6683, created_user_id: 1020, modified_user_id: 41 page: 6705, created_user_id: 1020, modified_user_id: 1020 This is the expected behavior. At least, it is on my machine. Before yesterday (or if you haven't replaced your PageFinder.php file with the one attached above), you would have gotten this: page: 1, created_user_id: 1020, modified_user_id: 2 page: 4459, created_user_id: 1020, modified_user_id: 41 page: 4602, created_user_id: 1020, modified_user_id: 1020 page: 4615, created_user_id: 1020, modified_user_id: 41 page: 6674, created_user_id: 1020, modified_user_id: 40 page: 6683, created_user_id: 1020, modified_user_id: 41 page: 6705, created_user_id: 1020, modified_user_id: 1020 Note it would only catch the 'created_user_id' part (or whichever you specified first), because fields native to the 'pages' table didn't consider ORs in the fields part of the selector. If you are getting something other than the expected result, can you post the selector you are using and the list of matching pages like above? Here's the code I used to do it if it helps: $results = $pages->find("created_users_id|modified_users_id=1020"); echo "<ul>"; foreach($results as $result) { echo "<li>page: {$result->id}, created_user_id: {$result->created_users_id}, modified_user_id: {$result->modified_users_id}</li>"; } echo "</ul>"; Also just to reiterate, this will only work if you are running the latest PW and have installed the PageFinder.php file attached above.

This is true that strftime() requires a setlocale() call in order to determine what language to use for things like month and weekday names. But this of course is the main reason one would use strftime() because it can do this (PHP's date function can't do this). ProcessWire will call setlocale() for you if the locale is defined with the language pack. In your language pack, you can look in the translation file for /wire/modules/LanguageSupport/LanguageSupport.module, and it should be one of the translation lines in there. Depending on your server, the locale may need to be adjusted to one that is installed in your server. You can type this to get a list of all locales installed on your server (in the unix shell): locale -a

Arjen, I can't seen to duplicate this. Here's the selector I'm using: echo $pages->find("buildings.building_name!=''); Check that you are running the latest ProcessWire, version 2.2.2. Make sure that your page(s) with the employee quotes are not unpublished or hidden. Double check that you've got all the field names spelled right and in the same case, between the field definition and your selector (we all make this mistake on occasion, so just double check).

I think there are situations where this is useful, and I even had one recently. I used a repeater with a 1-image field and a checkbox called 'published'. When I cycled through the repeater items to output the images on the front-end, I'd skip over any that didn't have $item->published.

Mike, I think we need more info. Is the external database to be accessed by a web service or directly through a DB connection? If DB connection, is it MySQL? What is the data? You mentioned creating an Inputfield module, which is something used for inputting data in the admin--is this what you need? Can you tell us more of the specifics of when you want to retrieve this data and what you want to do with it once retrieved?

If only there were more time. But I see all of this down the road, it's just a matter of time.

This is the correct syntax. It seems to work for me here when I test it. If you aren't getting the results you want, you might try adding "include=all" to the selector, as hidden and unpublished pages aren't included otherwise. If you find it still isn't working, paste in the result you are getting here. Then go back and edit those pages and click on the 'settings' tab. Click the 'info' fieldset to open it. It will say who created the page and who is the last modified user. Make note of which ones are incorrect, and whether it was the created or modified user that's incorrect, and include that information. This may help me to reproduce it.

Thanks Soma, I can confirm. I've added to my list.

You can use symlinks, but I also don't see any problem with just referencing the file you want directly. I'm not sure which multi site method you are using, but assuming you are using the built-in method with multiple site- directories. So if you want to include your /site-other/templates/home.php to include /site/templates/main.php, then you would just do this in your home.php: include($config->paths->root . 'site/templates/main.php'); Likewise for your base.css file, except that you would use a URL instead: <link rel='stylesheet' type='text/css' href='<?=$config->urls->root?>site/templates/styles/base.css' />

Sorry, I mis-typed it, that should be "filename" not "pathname". I updated the example.