ryan

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.

I don't know for sure, but am guessing yes. But that gets down into the jQuery plugin. I'm not looking to modify the jQuery plugin, but we can always offer suggestions to the author of it. This is again the behavior of the jQuery plugin. I suppose we could disable the plugin if there is only one image, but I'd rather leave the plugin to do whatever it does and upgrade it as the author puts out new versions.

I don't think that the oldfile.php is the problem, because it has a javascript save() (whatever that refers to), not a ProcessWire one. But looking in your Modules.pdf, I can see you've got a large amount of 3rd party modules installed. The more 3rd party modules you have installed, the more you have to keep track of in terms of versions and potential interactions. This is true of any CMS. It really expands the scope of where the problem might lie. I can also see by the PDF that you've switched back to PW stable? Just wanted to confirm that you are no longer on dev? If that is the case, make sure that you replaced the entire /wire/ directory when switching between stable and dev. The best way to do that is to rename the old wire directory, and then upload the new one from scratch, then remove the old one once you are sure it works. So far it sounds like we can narrow the issues down to two things: #1) large amounts of pages got unpublished; and #2) template access control settings disappeared. I'm not convinced that these things are related. So lets take a look at them separately. For #1 I would look at what modules can publish/unpublish, because ProcessWire has no mass-unpublishing capabilities in the core. In looking at your modules list, it looks to me like: SchedulePages, Page Publish/Unpublish and Batcher (if you had it installed). Of those, only SchedulePages and Batcher can do mass unpublishing, and it doesn't look like Batcher is installed. So I took a closer look at SchedulePages: the module looks to be nicely coded, but I spotted a problem on this line. // Select published sites with a publish_until date add them to an array. $published = wire("pages")->find("status=published, publish_until>0"); It's referring to "status=published" and "published" is not a status keyword recognized by ProcessWire. I think that the author really meant to do: "status<" . Page::statusUnpublished, because there is no published flag in PW, only an unpublished flag (since it's technically a bitmask). Why don't you try to run this selector "status=published, publish_until>0" in your Setup > Selector test, and see what it finds. Reading the rest of the function in SchedulePages, it still seems unlikely that this would be responsible for your unpublishing unless your server's system time inadvertently got reset to something earlier than it was supposed to be? For instance, what if your web host installed an update and had the server's time messed up for a few minutes? That could feasibly produce a mass unpublish event since this module performs unpublish actions connected with time. Edit: also want to add that it sounds like in your situation with numerous editors, a 1-click "Page Publish/Unpublish" module might be a little bit dangerous, as someone could unintentionally unpublish a page very easily without meaning to. You might want to uninstall this module, just to rule it out as being a problem. In this day and age when we can butt-dial people on our cell phones, we can also click links without knowing it. So a 1-click unpublish action is always going to be a potential problem. For #2, template permissions disappearing, this opens more questions: On how many templates are you defining access? Are there any other "superusers" in the system, besides yourself? How many roles are you working with? (just one editor role?) Do any of these roles have permissions to modify admin pages? You mentioned a "flooded with phone calls" – how many users are we talking about that have access to the admin, and are all trusted users? Are all of your users using secure passwords?

That seems unusual that the class exists even though it isn't installed? Thanks for finding that and posting a fix, I will update! …Though if the PDO class exists, then the PDO:: constants would presumably also be defined (since they are defined in the class). So I think another type of check would be necessary. But what kind of check, I have no idea. I'm going to hunt around stackexchange and maybe look into what other CMSs using PDO are doing.

You must have had the original HTMLPurifier module, which I mistakenly based the version number of the HTMLPurifier version number. I fixed that in the next one. Sorry about that. I just now pushed an update to CKEditor that should fix this.

@ceberlin: not a problem, but for the future please try to avoid posting the same message in two topics–I see this same message as a new topic, so I'll delete that one and reply to this one. It sounds like you are using a module that modifies ProcessWire's default access control: Page Edit Field Permission. So it's very possible that the rights you see in your page settings are incorrect. Instead, pay more attention to what your templates actually say, and how you've configured the PageEditFieldPermission module. Those have authority. The info you see in page settings is an informational-only table that reflects known static permissions and says nothing about runtime permissions attached from other modules or hooks. Most of the changes in the dev branch are specific to the LanguageSupportPageNames module and multi-language support in general. Are you using LanguageSupportPageNames or any kind of multi-language support? When you updated to the newest dev version (2.3.2), what version were you running before that? I replied to your comment on GitHub: Why linking to the mod settings pages in the admin of your site? I was thinking it might be because you want me to look at your settings for those modules, but note I can't see them since I am not logged into your admin. Are there any other 3rd party modules you have installed? If so, can you mention them, or post a screenshot. We'd want to see all modules that appear on the "site" tab of your modules screen. Also, since all of this is rather mysterious, I would also suggest checking your template files. Do you have any instances of save() in any template files or files they include? If I had experienced the same issues you have, the first thing I would do is check where I am saving pages (or anything else) in my site. I would suggest doing a: grep "save()" /site/templates/* Please post the code for any sections that perform a save of anything in your template files.

I don't think that is CollagePlus, since this module doesn't generate any images. Chances are you've just got some really large images. This more likely just has to do with the way PW's image selection has always worked. When designing PW's image selection, there was a conscious decision not to have it generate any images beyond the original. The benefit is that you don't end up with endless copies of images that aren't ever used on the front-end. The drawback is that if you've got big images, that can slow things down. But that's going to be the case regardless of whether you are using this module or not.

CollagePlus is a jQuery plugin by Ed Lea. It takes a list of images and converts it to a nicely formatted grid. With this module, we use the CollagePlus plugin to produce nice grid output for ProcessWire image selection. This applies to the images that you select when clicking the image icon from the rich text editor (TinyMCE or CKEditor). The idea for this is from the great Unify admin theme for ProcessWire by @adamspruijt. To use, simply install the module and it is ready to go. Requirements: This module should run on any version of ProcessWire. But to be on the safe side, it would be best to use version 2.2 or newer. If you are using version 2.3.1 (dev branch) or newer this module makes use of conditional autoload for increased efficiency. Download: http://mods.pw/54 or https://github.com/ryancramerdesign/JqueryCollagePlus or install via Soma's ModulesManager. For those running ProcessWire 2.3.2 or newer, you can also install it from your admin: Modules > new > class: JqueryCollagePlus.

Thanks Alessio, I will try to get this setup today.

Another approach is to do it with javascript. I like this method because it's just a progressive enhancement that uses the existing alt attributes (no duplication of text in the request). This is the method I used in the Foundation site profile, which takes the image "alt" attribute and expands it to a caption, like those seen on this page. Here's the JS that does it.

Check to make sure you have the latest version of MarkupHTMLPurifier. Based on the error message, I'm guessing you don't?

Guest means that no user is specifically logged in. But for things like your own bootstrapped scripts or other API usage, you can create a user specific to that need. Then in instances where you want them to be the current user (rather than guest) you can do a call like this: $u = wire('user'); // save current user, if you want to $users->setCurrentUser($users->get('api')); // set new user: api // // .. your code that does stuff // $users->setCurrentUser($u); // set back to the previous user, if you want to

From what Soma said, sounds like maybe it isn't that complex. I don't have much bandwidth to get into it now, but if anyone else wants to figure out how to do it and make a test case, we could support it in the core.

Radek–Thanks for your work in keeping this language pack up-to-date!

Thanks for creating this module Alevine. If you'd like, post to the modules directory at http://modules.processwire.com/add/

Ignore my mention of find()->first(). Looks like I was writing one thing, and changed my mind by the time I got to the code. Using first() would be fine, but I opted to just if(count($field_dupe_check)) instead. It should exclude trash unless you add "include=all" to it. No, because I used get() rather than find(). get() only ever returns 1 page. find() can return any number of pages. TextUnique enforces the uniqueness via a database index. So it's not necessary for you to perform your own checks, unless you want to manage the flow control yourself. Another way to do it would be to capture the WireDatabaseException that gets thrown, but I think your method is fine.