ryan

Where is the code being executed? It is in a template or somewhere else? When in a template, PW puts pages in a state suitable for output with a setting called output formatting. When output formatting is ON, PW takes care of making things output ready so text formatters are applied, dates look like dates (rather unix timestamps), and image fields that set set to have a max of 1 image are resolved to just 1 image (rather than an array of them). Based on the result you are getting, I would guess that $user has output formatting turned off. This would usually be the case in admin or command line API usage. You can check by doing this: if($user->of()) { // output formatting ON for this page } else { // output formatting OFF for this page } You can change the output formatting state by doing this: $user->of(true); // turns on output formatting $user->of(false); // turns off output formatting That of() function was added recently, so if you are using an older PW, you may have to do this: $user->setOutputFormatting(true or false);

I'm confused about what you mean about this: Is the field in question using the 'Repeater' fieldtype or the 'Page' fieldtype?

Hit reload in your browser -- This is an expected error message (in debug mode), but it should only occur the first time PW is loaded after upgrading. If that doesn't do it, double check that your /wire/ dir was replaced in full. Make sure you have a /wire/modules/System/SystemUpdater module in there. If you still get the error, execute this SQL query in PhpMyAdmin: ALTER TABLE fieldgroups_fields ADD data TEXT;

Those work because they are coming from a different file. The only translations that won't come through to /site/templates-admin/default.php are those that are defined in /wire/templates-admin/default.php. The intended way to pull a translation from another textdomain is to specify that as the second param to the __() function, like this: __('logout', '/wire/templates-admin/default.php'); Rather than having to type that into every __() function call, I recommend just putting it in a variable at the top of your file: $td = '/wire/templates-admin/default.php'; And then just doing your calls like this: __('logout', $td); So if you were copying over the /wire/templates-admin/default.php into /site/templates-admin/default.php, then I would just change all the __('text', __FILE__); to __('text', $td); This is only worthwhile for instances where the untranslated text is going to be exactly the same between the one in /wire/ and the one in /site/. If you are adding new/different translatable text to your custom admin theme, then no need to have it reference PW's default admin theme, as that text won't be translated there. So for those instances, you would just do this: __('new text to translate'); __('new text to translate, __FILE__); // same thing: less pretty, slightly more efficient

Maybe there's a better way I'm not thinking of, but one possibility might be to duplicate the login post to the other domain, from the client side with a little jQuery: if($input->post->submit_login) { $username = wire('sanitizer')->username($input->post->username); $pass = $input->post->pass; $user = wire('session')->login($username, $pass); if($user) { echo "<h2>Login successful!</h2>"; echo "<script type='text/javascript'>"; echo "$(document.ready(function() {"; echo "$.post('http://es.domain.com/{$page->url}', { username: '$username', pass: '$pass' });"; echo "});</script>"; } else { echo "<p>Login failed </p>"; } }

Welcome to the forums Scott! You are definitely on the right track. I do the same things that you mentioned. I also sometimes use the homepage template for holding fields that will be used site-wide.

I think it's best to follow the source on GitHub with your dev/staging server, and then push to your live server when there is an update or fix that you want to have on the live site. I generally think it's best not to disturb a live site if everything is working well, though minor updates are very unlikely to disturb anything. As soon as there is any reason to update it, backup your database, /wire/, index.php, .htaccess and replace them with the ones from the new version. Regardless of which way you go, always test updates before making them permanent.

@designofseven I definitely agree with you about changing the core. But I think you only have to look at it as a temporary thing until PW 2.3. If you want to give it a try, here's what you have to do: 1. Edit /wire/core/Session.php and change this: class Session extends Wire implements IteratorAggregate { to this: class WireSession extends Wire implements IteratorAggregate { 2. Edit /wire/core/ProcessWire.php and change this: $session = new Session(); to this: $session = new WireSession();

Are you including /wire/templates-admin/topnav.inc or outputting your own top nav? If you are including it from /wire/ then the translations in there will still work. None of the other translations should pull over from the /wire/templates-admin/ textdomain, since your admin theme is asking for translations with a /site/templates-admin/default.php textdomain. If they were working before, they probably shouldn't have been But that's why I was wondering if you might be including the topnav file from /wire/templates-admin/topnav.inc?

Welcome to the forums designofseven! I'm looking forward to using PHP 5.3 namespaces so that this would not be an issue. However, we've still got a lot of people using PHP 5.2 and not sure we can safely require 5.3 just yet. Perhaps we can test the waters with PW 2.3. For now, I would to a search/replace on whatever system is not in control of the Session. So if it's PW, then you could do a global search/replace of Session with PWSession, or if it's Kohana then you could do a search/replace with KSession.

You are right about this, because the module's path+file forms it's textdomain, and that's the primary key for PW to connect the file with the translations. I'm just wondering if I can somehow update the translation functions to use the location of the symlink rather than the path it point to. PW finds the textdomain by using the __FILE__ magic constant, and this returns the actual path of the file. I don't know if there is a way to get PHP to recognize the path of the symlink, at least not in a similar manner?

The issue here is the textdomain, which is based on directory + file. Files in /wire/templates-admin/ have a different textdomain than files in /site/templates-admin/ (since 'wire' and 'site' are different dirs). You should be able to resolve it by specifying the textdomain as the second param to your __() calls: $textdomain = '/wire/templates-admin/default.php'; __('text to translate', $textdomain); I would probably set that $textdomain var at the top of your default.php and then send it as the second arg to all your __() calls. However, if you've got any text translations unique to your theme, you'll want to leave off that $textdomain argument.

Welcome to the forums Andy and thanks!

When you populate a date into the field via the date picker, it should populate it in with this ISO format: YYYY-MM-DD. This is a format recognized by both strtotime() and jQuery's datepicker. So once you hit save, it should be in correct Finnish format. It sounds like that's not what it's doing in your case? Can you describe more? We will probably go with predefined date formats that both PHP and jQuery can recognize, as soon as there's time to get into it.

Tinacious--you'll see Radios as an option with Page reference fields. All single/multiple selection in ProcessWire is handled with the Page reference field. You'll see it when you create a new field and it asks you to choose the type: choose Page.

Using $page->render() doesn't have anything to do with ajax. It's the method that PW uses internally to render a page, but it's exposed in the API in case you want to render some other page. The most obvious use would be using pages as blocks of content for placement in other pages (partials). I used them recently for having sidebar-features. The editor would select from a group of pages in an asmSelect list (page reference field), and those pages would be rendered in the sidebar. When it comes to ajax, I think you are better off just loading at the URL the page lives at, rather than asking another page to render it, and passing along an ID or something. It's not ideal to ask one page to render another where the other is specified by some dynamic user request (ajax or otherwise) because that could open up security concerns.

No need to remove it Charliez. Hopefully some other people will see it there and decide they want to check out ProcessWire. I'm pretty impressed with apigen's results. Seems like a lot less hassle than the old PHPdoc.

Soma, I've added this capability to Sanitizer. To use it, specify Sanitizer::translate as the second param to $sanitizer->pageName(), i.e. $name = $sanitizer->pageName($name, Sanitizer::translate); To make it work with the ImportPagesCSV module, edit the module file. Search for this: if($name == 'title') $page->name = $this->sanitizer->pageName($value); and replace it with this: if($name == 'title') $page->name = $this->sanitizer->pageName($value, Sanitizer::translate); I'm going to make the same change in the module itself here, but need to think a little more about how to avoid messing up anyone that's already using it. If someone is already using the module, then upgrades, it's feasible this could cause it to create new pages when it should be updating existing they had imported in a past version. I'll probably make it a config option or something.

Soma I hope you don't mind, but I took this functionality and brought it into the core. After using your module for several days, I got used to the behavior and found I couldn't live without it. So it had to go in the core. Rather than integrating it in the session, it is now part of the JqueryWireTabs module (all JS) and uses cookies to remember tab positions. I figured I might as well let that WireTabs plugin be responsible for remembering the tab states. I wasn't sure if everyone would want the behavior or not, so it is configurable under Modules > Jquery > Wire Tabs. By default, it only remembers tab positions between form posts (which I think is the most natural behavior). But you can set it to remember all tab positions between pages, or disable the behavior entirely.

I don't think this sounds like a caching issue. Adam is right, if you are logged in and have edit access, you aren't getting anything cached unless you've cached it yourself manually (using the MarkupCache module). Alan is it possible that any of the pages in question were unpublished or hidden and not participating in the count? If not, I'm honestly not sure what could have caused the tags.count to not work properly in this example here. That particular selector translates to a MySQL count() query, so its a surprising one to fail. If anyone finds that it can be repeated, please let me know and we can fix it. Ouch, this doesn't sound fun. I won't ask you to try and reproduce that one. I'll try from here. Some browsers (Firefox especially) do strange things to forms when you hit reload. Not sure if it's still the case, but Firefox used to advance radio buttons to the next item every time you hit reload in a form. I think some of this can be resolved by setting an autocomplete attribute to off on the <form> tag (and we may need to do that on the form in question).

Also wanted to add that you can do this: if($user->language->isDefault()) { // user has the default language } Having a default language is required by the system, but it doesn't matter what language you decide for it to be. However, I would suggest making it whatever language the homepage of your site is in by default.

Web sites aren't just databases, but files too (which may be version tied to the database), so I don't see anything that operates just on SQL queries as being realistic. Versioning is one thing (which can be done), but migrating in the manner you mentioned is something else. I don't think you should ever consider "live" as something that can be frozen while you go to work on dev, though I guess that depends on the case. I know I couldn't freeze any of my live sites. Migrating file-based assets (templates, js, css, etc.) is a pretty simple matter. But migrating databases gets more complicated. Future tools for migrating data in ProcessWire will likely take a web-service approach (two sites talking and sharing JSON) rather than one involving sharing of database queries.

This looks very interesting--thanks for setting this up charliez! I do worry a little about documentation like this, because it steps outside of our public API. I don't consider every function in PW to be part of the public API that folks should use (the majority of it is not). ProcessWire isn't meant to be that low-level of a framework. There are so many components that are really just there to support the public API, rather than be part of it. Looking at the docs in this manner loses all context of that. The cheatsheet really has the right context. I would just suggest that people use our regular API docs (especially the cheatsheet) and then use something like this apigen documentation for zeroing in on more detail about a specific function or class, if they need it. I think the apigen documentation could really be useful for contextual links to more detailed function reference, where applicable (like in links from the cheatsheet). But I don't suggest integrating functions that aren't in the cheatsheet into your projects. The public API in ProcessWire is a constant, but everything else can change with versions. Also, I'm not so sure what I think about this service hosting our documentation (I don't know them well enough yet), so I went ahead and copied it to here: http://processwire.com/apigen/

The replacements defined with the InputfieldPageName module are just used in that live javascript conversion. Whereas $sanitizer->pageName uses PHP's iconv() to perform a UTF-8 to ASCII conversion (when the $beautify param is set to true). When the $beautify param is omitted, then it just removes anything invalid, converting to a dash. They don't use the same method because the pageName() in Sanitizer needs to be predictable so that we know it's always going to return the same thing on any installation and at any time. Plus, it needs to be really fast, because it's potentially called hundreds or thousands of times per request. Whereas the one in InputfieldPageName is done as a live translation that you can observe as it does it (and thus can be configurable), and it's okay for it to be slow with lots of RegExps. The consistent behavior with pageName() is actually kind of important to the CSV import module, as the page names are used as a primary key and become a means of determining if something should be updated or created new. Though if you'd never imported pages before, and you weren't ever going to change the InputfieldPageName translation string further, then it wouldn't matter. It sounds like in this case, we need another PHP-based method of converting page names that also does translation, like the JS one. Then you could modify the CSV import module to call upon that rather than $sanitizer->pageName. I'm thinking the PHP based method should probably be defined directly in the InputfieldPageName module, since that module owns the custom page name translation settings. Once in place, we could still make it accessible through Sanitizer perhaps through a new pageNameTranslated function, or something like that.

Thanks Rob, got your message and will take a closer look today. Regarding the functions you mentioned: • wakeupValue() converts a file from a basic storage type (typically an array) into it's representation in ProcessWire. Most often this is used to translate the raw value from the DB into the live value for runtime. • sleepValue() does the opposite of wakeupValue() and translates a runtime value back to it's basic type for storage. If you are just dealing with a simple type like an integer or a string that are represented in the database exactly how they are at runtime, then wakeupValue() and sleepValue() don't need to do anything at all (other than return the value they were given). So these functions really only come into play when the field's value has to be stored differently than it would be presented at runtime. This would be the case for anything that is presented as an object at runtime. Since an object can't just be "stored" and still have its components be searchable and sortable in a database, it needs to be translated to/from fields in a DB table. Likewise, if you are sending object field values to/from JSON/XML web services, you probably want that object represented as an array, so that it can be encoded by XML or JSON. • sanitizeValue() is entirely unrelated to the other two functions (though you may see it called in series with them). But it does nothing other than sanitize a value that is assigned to a $page. So lets say that you have a field called 'myfield' and this API call gets executed: $page->myfield = 'my value'; That value gets passed through the sanitizeValue() method for whatever fieldtype is used by 'myfield'. After passing through sanitizeValue() it gets set to the $page. The sanitizeValue() method is just a way to ensure that invalid data doesn't get assigned to the page. So if the fieldtype used by 'myfield' expects it to be a string, then its sanitizeValue() method should ensure that whatever it returns is a string, regardless of what it's given. Or if you want, you can have it throw an exception when it receives invalid data. But here's what a sanitizeValue() method might look like for 'myfield': public function sanitizeValue(Page $page, Field $field, $value) { if(!is_string($value)) $value = (string) $value; return $value; }