ryan

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.

_('text') is for gettext, but ProcessWire doesn't use gettext. I think that _() was actually meant to be a __('text') or a $this->_('text') ? Those are the ProcessWire translation functions, among others.

I'm not at my desktop computer, but think it is MySQL 5.5.25 (under MAMP) that I'm running. But you are right that assigning the default value to the text field in this module's schema wasn't right, so I pushed a fix for it a couple days ago.

I definitely did try it with a concat field--I still have test_concat_renamed sitting in my fields list. But I see what you are getting at: since this field has no tables, why is it apparently trying to rename tables in your installation? That's a mystery. I will take a closer look and see what I can find.

Also, don't forget about the "hidden" checkbox on every page's "settings" menu. That by itself would enable you to hide items from the Foundation menu. This is the method that is used natively in the profile to hide things like the search page from appearing in the menu.

It's best to have your translators do their job of translating static text once you've finished your development work. Either that, or like Antti said, use multi-language fields for stuff that you think may change regularly.