ryan

Sounds good Steve, we look forward to seeing you around here. When you get to the point of trying to accomplish specific access control scenarios, post more and we can help you solve them.

There hasn't ever been a "status=published" option in ProcessWire that I'm aware of. The status=published would simply translate to a "status=1", which basically means "any page." In this case, the "status=published" seems unlikely to be the source of the problem by itself… even if it isn't a valid option, it doesn't seem to affect the result in a way that would matter. Given that the code still qualifies the publish_until date later, I wasn't able to logically figure out how it could unpublish a bunch of pages, nor could I duplicate the issue myself. The only thing that seemed like a possibility was if the server's date got majorly screwed up, there could be a potential problem. Many servers do nightly maintenance services, and I'm wondering if one of them breaks the clock for a few seconds or something. That was the only thing I could think of?

Thanks for trying it out. I didn't realize that locale settings went as far as typecasting. Seems like typecasting should be about maintaining a type for the language, not for display. While we could set the LC_NUMERIC, and maybe that's the right way to go (I'm not yet sure), I'd be worried about the situations when someone wants to override the numeric stuff. Perhaps FieldtypeFloat needs to do this in the sleepValue method: save the locale, set it to something compatible with PHP and MySQL, then set it back to whatever it was. That seems like maybe the way to add this with least impact.

The PageAutocomplete can be used with a custom selector. If we're talking about a potentially huge list of pages, that's what I usually use. If needed, you can also set the "label" field to be "path", so that you are still aware of where a page is in the structure.

Welcome to the forums Steve! In ProcessWire "superuser" is a special role that can do everything, regardless of any access/permission settings. Managing fields templates and users is typically the job of superuser. If you've got a non-superuser with "user-admin" permission, then they won't be able to edit or add superusers. But they'll be able to edit/add anyone else. Templates and fields are only accessible to superuser. Actually you could add a template-admin or field-admin permission to a user to give them access to these things, but the need is very rare. That's why these permissions are not included by default with PW. This is only the case if the user-admin is creating new roles and assigning them to templates. It doesn't sound like your user-admins would need that ability. Your admin user would have a role with page-edit permission, and you'd assign that role to any templates used by pages you want them to edit. Beyond knowing that "superuser" is allowed to do anything, ProcessWire doesn't necessarily know that one role is beneath another, and I'm not sure that it could unless you had some of your own logic to it. So you'd probably want to create your own front-end user tool for this, use hooks, or modify the behavior of the existing ProcessUser module. You can do this relatively easily by copying the existing /wire/modules/Process/ProcessUser.module to /site/modules/ProcessUserCustom.module, modify it to work the way you want it, and edit the page /admin/access/users/ and change the "Process" field on that page to your custom version of it. Though if the intention is simply to have the ability to add or delete users easily, I think a front-end tool (or your own admin tool) would be simplest. That's because you could take out the role considerations (less for your editors to think or know about), handling that automatically based on your needs. All of your access control scenarios seem within the scope of the system, except for the one that needs to know about one user defined role being considered above another one. But there are numerous ways to handle that, like mentioned.

The PageArray part is called "type hinting" in PHP. It is the developers way of telling PHP that it should throw an error if it's given something other than a PageArray. That way the developer doesn't have to write extra code in the function to make sure it's been dealing with the right type of info passed to it before attempting to use it. For the consumers of the function (you and me), it's also useful just purely for readability and knowing what it expects you to give it. It's also nice to know that you'll get a consistent error immediately if you give a function the wrong info. Like if you passed in a Page rather than PageArray, you'd know right away, rather than trying to figure out for some time why the function isn't working. If we had a function that we wanted to accept multiple types, like say arrays, strings and ints, then of course we would not want to type hint like that. We would probably just have myfunction($something) instead.

I'm trying to reproduce this so far, but can't. I added this code to my /site/templates/admin.php, but only get 1 message when I save a template or field: $templates->addHook('saved', function($event) { $this->message('Templates "saved" hook executed'); }); $fields->addHook('saved', function($event) { $this->message('Fields "saved" hook executed'); }); Are there any other factors, like other modules or is it possible your hook is getting attached twice?

This was fixed, and localUrl() should be possible with 404 pages now too. Not to mention, multi-language 404 pages are supported as well. But you'd have to be running a dev version that is pretty new (I think this was pushed to the source a week or two ago).

ProcessWire wants to have a local path to save files when you upload them. But using a solution like Teppo's, where you alternate the URL where they live, is certainly a possible way to redirect requests for any file to an alternate location. Another possibility is that I could make PagefilesManager::url() hookable, so that you could modify it with a hook. This would probably be the cleanest method, and I'll be happy to add the hook if anyone wants it. However, you would still need to be responsible for making sure that the files that live in /site/assets/files/* manage to find a way to their new URL location, whether it's literally having them copy to that location, or it's a directory mapped to another drive or server, etc.

I can't wait till we get to 50k massages. I wonder what WillyC will come up with for that event.

Are you running an opcode cache (APC?). If so, put this in a PHP file and run it: <?php apc_clear_cache(); I have no idea if that's the problem. But any time I get weird/inexplicable behavior from PHP, that usually fixes it. If that's not it, then it seems like the only thing different about your module from others would be the name. Hard to imagine it could be an issue, but I would try renaming it, just in case. If not that: Turn off computer. Wait 30 seconds. Turn on computer?

We have append() for consistency with jQuery. I also like the team of prepend/append naming (it sure beat's PHP's unshift/push terminology). But I also think the term "add" is ultimately more friendly, especially when talking about adding an item to a group of items. As a result, I tend to use add() when adding items and append() when moving things around. Ultimately they do the same thing, but one may be more readable than the other depending on the context. Use whatever you prefer.

That's correct. Though you could bypass it by specifying your own selector for what pages should be selectable. But if you are specifying a "parent" then it's assumed you are making the children of that parent selectable. If you use an input type that supports hierarchy (PageListSelect or PageListSelectMultiple) then the parent is considered the starting point, and you can go beyond just the direct children.

Very cool, thanks for sharing this with us. I've not had experience with a Raspberry pi computer before, but it sounds very compelling.

That's essentially what the multi-language support solutions are doing. PW 2.4 doesn't change or add anything in this regard. Careful with use of the term "module" in this context, just because that means something different in ProcessWire (a plugin). And things like blog and search are not modules in ProcessWire, but things that you build with pages. However, you can restrict a search to any branch in the tree just by calling find() on the page that represents that branch, rather than $pages. For example: $pages->find("your selector"); // searches entire site $pages->get('/products/2013/')->find("your selector"); // searches everything below /products/2013/ $pages->get('/products/2013/')->children("your selector"); // searches only immediate children of /products/2013/ There are forum and shop modules (by @apeisa). But these are both labeled as "proof of concept" modules, meaning they are not necessary turn-key solutions so much as solutions for you to examine, learn from, build from, adapt to your needs. I also don't think that these modules are deigned for multiple-installations on the same site, but not positive. I'm not sure you need to let the needs of user accounts dictate the approach. I personally would be more inclined to isolate the user accounts from the sites for this particular need, perhaps running a separate PW installation that is dedicated to just managing the user accounts for all the domains. But I'm not really sure what the best route is without giving it more time. There are already forum solutions out there that people have spent years developing and making them the best. IPBoard is one of them. We couldn't duplicate that unless we also spent years doing the same. Regardless of how many forum solutions get built as ProcessWire modules, I don't see us moving away from a dedicated platform like IPBoard for this.

I'm not really sure what the best solution is to this, and how many other locale rules we might have to potentially account for (if any?), but one solution would be for FieldtypeFloat::sleepValue to replace commas with periods. Do you want to try adding the following to your /wire/modules/Fieldtype/FieldtypeFloat.module, or replace with the attached file? public function ___sleepValue(Page $page, Field $field, $value) { if(strpos($value, ',') !== false) $value = str_replace(',', '.', $value); $value = (float) $value; return $value; } FieldtypeFloat.module

This is a reply to a PM from @dragan that is a continuation of his question above. I'm copying my response here just in case helpful to anyone else. FormBuilder is multi-language capable, at least the latest version is. Make sure you have the latest from the support board. It does need the $user->language set to the right language ahead of time. Even though FormBuilder is multi-language capable, some people still choose to just create separate forms per language, so that the resulting form submissions go into separate locations. If your needs are diverse, you may find creating separate forms per language is still a good idea. But give the multi-language form option a try just in case. The only thing to mention is that "select" fields are not (yet) translatable, so avoid using them unless for numbers, etc. You can still use Page reference fields to handle multi-language selects though (the same way you would in PW's admin). I'm not totally clear about what multi-language solution you are using, but your forum post mentioned example 1. That has since been removed from the old location since Multi-Language page names are now recommended for the previous examples. However, I'm keeping the old examples here now, in case you still want to reference it. Assuming you are structured similarly to example 1, adding the language URL segment to your URLs is something you have to do manually. It could also be done with a hook, but I would stick to doing it manually until you know everything works. ProcessWire 2.3.2 uses the new method documented here, rather than the one in example 1. But that documentation won't be applicable unless you abandon the method you were using (example 1). So if you've already invested a lot of time in pursuing example 1, then you may want to stick with it. Because it detects the language from the URL segment, you need to make sure that you have URL segments enabled for templates where you plan to use it (Setup > Templates > your template > URLs > URL segments). You need to code in your template files to detect the language. For example: if($input->urlSegment1 == 'de') $user->language = $languages->get('de'); That would need to be done first thing. You may prefer to put code like that in a common/shared include file, so that you only have to write the code once. When outputting URLs to other pages, you need to include that language segment as well: foreach($page->children as $child) { $lang = ''; if(!$user->language->isDefault()) $lang = $user->language->name; echo "<li><a href='$child->url$lang'>$child->title</a></li>"; } That way when someone clicks on a link, the language will be retained in the URL, i.e. /contact/de rather than just /contact/ Ultimately, this method is kind of a pain next to the multi-language page names method, which does all the work for you, and lets you actually have translated URLs. But unless it's a very big site, I think you'll find the example 1 method to work just fine, so long as you keep in mind that you have to manage: 1) setting the language; and 2) making your URLs include a language segment.

I've posted a new documentation section on how to use the multi-language page names / URLs in ProcessWire: http://processwire.com/api/multi-language-support/multi-language-urls/

Looks good ffub! I don't yet have a mailchimp account, but this might be a good reason to get one. They are a PHP, Atlanta-based company too, after all. You can always used a "saved" hook (which gets called after a successful save) rather than "saveReady". Or you could use both, letting "saveReady" populate something that is later used by your "saved" hook. But the only way to grab a previous value before save is to pull it directly from the DB. i.e. SELECT data FROM field_email WHERE pages_id=$user->id

Unless you've found more info about it, then I'm not sure we can definitely say it was SchedulePages. But it does seem like the most likely at this stage. Also glad to hear there is an explanation for the loss of template role settings. Though I'm still not sure how switching between master and dev could do that (there have been no core changes in this area), but if you switched back to a much older version than 2.3, then it's possible. Glad it sounds like things are coming together and working well!

Assuming the other domains are completely different (and not just subdomains) it is a little tricky to have the user logged in all of them, unless you are using some external service to manage the logins (whether one you've written or an already existing service). For instance, consider that Facebook recognizes you as logged in as you browse through other websites. But if you are looking for a simple solution, one possible is to use Javascript to duplicate the login form POST submission to other sites. I don't know of a way to do it without Javascript just because the client side (user) is the one that must actually login, so Javascript being client side, lets you perform that action for them without them knowing it. This is just untested pseudocode, but hopefully it gets the idea across. <form id='login-form' method='post' action='/login/'> <label><input type='text' id='user' name='user'> Username</label> <label><input type='password' id='pass' name='pass'> Password</label> <input type='submit'> </form> <?php if($config->httpHost == 'maindomain.com'): ?> <script> $(document).ready(function() { $("#login-form").submit(function() { var data = { 'user': $("#user").val(), 'pass': $("#pass").val(), 'submit': 'submit' }; $.post('https://www.otherdomain.com/login/', data); $.post('https://www.adones-site.com/login/', data); }); }); </script> <?php endif; ?> Now I'm not positive it would work exactly like this. You might have to open an invisible iframe to each of those external sites first to establish a session, but that would be fairly simple, just by adding some hidden <iframe> tags to the login forms of those other sites after your <form>. There may be other factors too, but I think this would work. Your /login/ page would also need something to detect when it is being submitted to, and login the user in: <?php if($input->post->user && $input->post->pass) { $name = $sanitizer->pageName($input->post->user); $user = $session->login($name, $pass)); if($user->id) { // login success if($config->httpHost == 'maindomain.com') $session->redirect('/wherever/you/want/'); else echo "Success"; // presumably this will never be seen } else { // login failed if($config->httpHost == 'maindomain.com') $session->redirect('/login/'); else echo "Failure"; // presumably this will never be seen } }

if($user->isLoggedin()) { // display ads from your city } else { // display all the ads }

If the call is within a class that extends one of ProcessWire's (like Wire or WireData), it's actually better to use $this->_('your text'); as there is a little bit less overhead with that call than with a __('your text'); call.

I don't think you can use these two modules together because the ImportPagesCSV module is purely an interactive module used from the admin. It doesn't have an API that you can code around. Nor does it need it, because the module is simply a front-end to ProcessWire's API in terms of importing pages. So to achieve what you are asking (automated background importing) LazyCron will be a fine way to go (and regular Cron even better), but you will handle the import of the CSV yourself rather than using the ImportPagesCSV module. Though you might find it handy to look at the code in ImportPagesCSV to see how to import a CSV file... it's actually very simple, and done with the fgetcsv() function native to PHP. Everything else will just be typical, easy API usage of ProcessWire to create or update pages. Take a look at the while() loop in the first post of this thread, and pretend that it were looping through the results of fgetcsv() rather than a database row. The implementation would be essentially identical.

The loadPageField() method is what loads the raw value from the database and returns it as an array. Most Fieldtypes just inherit the base Fieldtype method of doing this. But in this class, it has to be implemented since it doesn't actually load anything from the DB. The wakeupValue() method is what gets called to convert a raw value (typically an array) to an object, if required by the fieldtype. For instance, the Page reference Fieldtype converts it from an array of page IDs (numbers) to a PageArray of Page objects. If the raw value doesn't need any conversion to something else, then the function can just return the raw value. wakeupValue is typically dealing with values loaded from the database (via the loadPageField method). But wakeupValue can't assume that, it doesn't know where the value came from... it could have come from some other web service, data source or import function. That's why loadPageField and wakeupValue are separate things, and both necessary. The sleepValue() method is the opposite of wakeupValue(). It converts the value from a runtime representation back to a raw representation, suitable for storage in a DB or web service feed, etc. For instance, in the Page reference field type, it converts the value from a PageArray back to a regular PHP array of page IDs. If the page is being saved, the savePageField() receives the value generated from sleepValue() and saves it to the DB. It expects that value to either be a raw value: array of [column => value], string or integer. Like with loadPageField, most Fieldtypes inherit this from the base Fieldtype class. Lastly is the formatValue() function, which is what is used to provide any additional front-end, runtime formatting for a value where necessary. For example, text-based Fieldtypes use this to run formatters like Markdown or HTML entities. The formatValue function is only called if the "output formatting" mode for the page is ON. The formatValue() function is called on every access to $page->your_field_name, so the unformatted value is always still retained with the page. Given the above, there are a few different ways you could approach implementation of these functions. For instance: Make loadPageField return the result of runSelectorQuery Make wakeupValue return the value it's given, assuming it's a PageArray. If it's a regularly array, assume it's page IDs and convert to a PageArray. Make sleepValue convert the $value (PageArray) it's given to an array of Page IDs and return that. Another possible approach: Make loadPageField return the selector string Make wakeupValue convert the selector string to a PageArray (calling your runSelectorQuery) Make sleepValue return the selector string In this case of this Fieldtype, you'd basically just have to think about how you'd want the value represented externally in a CSV file or web service (for instance). Would that be an array of Page IDs or the selector string the generated them? The selector string may be more portable in that context.