ryan

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.

The problem here is that ProcessWire doesn't actually support OR selectors for fields native to the 'pages' table (id, modified, created, modified_users_id, created_users_id, status, name). You can use OR in the value, just not in the field. So the query is just getting converted to this: created_users_id=1009 The reason there isn't OR support for those 7 native fields is just that it hadn't come up as a need before. However, I just added it after seeing this message. I want to test it for a day or two before committing to the source to be safe. But attached is the updated file (/wire/core/PageFinder.php) if you want to test it out. PageFinder-php.zip

I'm always here to support any projects being developed in PW. But when it comes to development time, I mostly have to focus on the things that help to make ProcessWire and my business marketable to my clients. Right now, there isn't a demand for this with my own clients, but maybe there will be in the future. I hope there is because I agree about the value of this and am thrilled with the work that's been done thus far. This project is already under great direction and doesn't necessarily need me. One of the reasons for lack of demand with my own clients has to do with recent draconian PCI compliance rules. These rules push clients (and developers) to want to delegate the PCI compliance to dedicated service providers like Shopify, Volusion, etc. There is still a place for the self-hosted and open source carts though, it just means that the checkout strategy has to be different and a little less open/flexible from what it has traditionally been.

Alan, none of the updates should require running an install script. PW keeps track of an internal system version for things like DB modifications. If it detects that the system version has changed, it runs it's own install script behind the scenes on the first request after it detects it. For instance, a DB modification took place about a month or so ago, but I don't think anyone knew it.

I need to update that list. Actually, I need to get rid of that list and code a real modules directory.

I agree with this. But in this case, I think it should be okay because PW performs a secondary filter on the URLs that go into it. That .htaccess line that was removed is more like a first defense to to save resources and not load PW at all when we know the URL is going to be invalid. Removing that line makes things a little less efficient, especially when getting bombarded by somebody's vulnerability scanner. But I don't think it is a security concern. So if removing that line makes it work on IdeaWebServer, then it should be okay. It would still be good to find a replacement rewrite rule, but not an urgent thing.

I'm out of resources for taking on any new work too, but always happy to coach you through figuring out how to do it yourself. Tell us more about what you are trying to do?