Jason Huck

Oh, of course. That makes perfect sense, I just wasn't thinking about it properly. Thanks!

How does that work? Do you have two separate translation files, with the same keys? e.g., english_translations.php would contain _('key1', 'Hello'); and spanish_translations.php would contain _('key1', 'Hola'); ?

Looks like $foo->set('name$lang', wire('sanitizer')->pageName($value)); does the trick.

What's the correct equivalent of this? $foo = new Page(); $foo->name->setLanguageValue($lang, wire('sanitizer')->pageName($value)); I get that 'name' isn't a field like title, etc. and thus doesn't have the setLanguageValue method. I also see where the data is stored in the database. But what is the proper way to set that value via the API? Thanks! Jason

Thank you Sérgio, that's a perfect solution for this particular situation!

What's the best way to create a processwire site with a bilingual (Danish and English) front end, where Danish is the default language (no language code in the URLs) and English is the secondary language (URLs prefixed with /en/)? There is no language pack available for Danish, and the site administrators don't mind if the back end is in English only. I'd like to use the built-in multilingual features of processwire as much as possible. I started out with an English installation and added an empty language pack for Danish, but it's apparently a bit of a pain to actually switch the default front end language after the fact. I can't remove the language prefix (/da/) for the Danish URLs (under Pages -> Home -> Settings). If I try, it just adds /en/ there. And, URLs without a prefix still default to English. Should I: (a) start with a new installation and select Danish as the default language from the beginning? Can I even do that when there isn't a real language pack to use, or will it cause problems? (If this is what I need to do, is there a way to hack an exported site profile to switch the default language so I don't have to start over completely from scratch?) (b) hack the current installation somehow to switch the default language without starting over? © resign myself to having a language code prefix for both languages? (I don't want to introduce a bunch of redirects into the equation.) (d) something else? Suggestions appreciated! Jason

Anyone using this module successfully with PW 2.7.x? I've had no luck so far getting PW to even recognize that it's available to install. Edit: Installed a completely different module, and afterwards, this one magically appeared as available to install.

And now this afternoon, mysteriously, with no changes from me, it is returning a 200 and Webmaster Tools accepted it just fine. So, never mind, I guess...

I can see the XML, and it's correct, but the HTTP response code returned in the page headers is a 404 instead of a 200. Webmaster Tools complains about this and won't import the sitemap, even though the *body* of the response is fine.

I'm getting a 404 response when I hit mydomain.com/sitemap.xml. The sitemap data is there, and there are no errors. I understand that the module works by hooking into the 404 page, but I also see in the module code that the header is explicitly being reset to 200. This is an issue because Google Webmaster Tools won't accept the sitemap due to the 404 header. Any suggestions on how to debug this? I assume no one else is having this issue, so it's probably something unique with my setup, rather than an issue with the module itself, though I am not doing anything in my code to override the HTTP response code, to the best of my knowledge.

Thanks for the suggestions. I looked at the built-in field-level export/import (didn't even know that existed) as well as the Migrator module, but ultimately ended up syncing everything with Navicat. In this particular case there was very little data that differed on production that needed to be preserved, and most of that was self contained in its own tables (e.g., FormBuilder forms and entries), so it wasn't that difficult to isolate. I will keep these other options in mind for the future when circumstances might be different.

I've got a large number of new field definitions and associated data in a development site, all of which needs to be deployed to a site that's already live in production. I know I can export/import the field data via CSV, but I'd also like to avoid the laborious process of manually recreating all of the field definitions. Looking at the database schema, it seems like I could do a structural sync (e.g., using a tool like Navicat) to add empty versions of all of the new per-field tables ("field_myfieldname"), then sync the data in the following tables: fieldgroups fieldgroups_fields fields fieldtype_options It looks like that would recreate the structure. I wouldn't sync the actual field data that way, as it looks like an easy way to get ID mismatches. I can test this on a copy of the database, but thought I'd get opinions here. Seem like a reasonable approach, or bad idea (because...)? Thanks, Jason

A custom input field that accepted scientific/decimal notation and properly round-tripped it to the database would be pretty handy. It'd be nice to be able to input, e.g., "1*10^16" instead of "10000000000000000."

+1. Clients don't know the difference between baseline and progressive JPEGs, they just upload whatever they've got and then call when it doesn't work.

FYI, we have observed that if the source image is a progressive JPEG, crops created by this module will always start at 0,0 (the top left corner), regardless of the position specified by the user when creating the crop. Re-exporting the source images as regular, non-progressive JPEGs allows them to be cropped correctly.

Does anyone happen to have a language pack for Danish? I don't see one in the Language Packs forum or the corresponding area in the docs/modules portion of this site. Sorry if I just missed it. Thanks, Jason

Since ->render is just another string, overriding an individual field value like ->seo_image doesn't change it. The only options appear to be (a) generating the markup myself using all of the individual field values (thus not using ->render at all), or (b) operating directly on the value of ->render, e.g. via regex. Although (a) is the more flexible, future-proof option, at the moment I am using (b). If a future version of the module changes the markup, or I need more flexibility, I'll revisit it.

Sorry for the cross-post, wasn't sure if my question was module-specific or more of a general api question. Sounds like the answer is "no", since ->render is pre-rendered. Thanks!

Is it possible to reassign field values from within a template? Not save back to the database, just override in memory. I'm using the MarkupSEO module, and want to use its built-in ->render function, but I want to tweak some values first, e.g.: $page->seo->{"og:image"} = '/path/to/image.png'; $page->seo->render; Possible?

I may have missed this, but is there any way to override a value at runtime, prior to calling ->render? I'd like to programmatically insert a page-specific value for og:image, something like: $page->seo->{"og:image"} = '/path/to/image'; $page->seo->render; Any way to do something like that? Thanks! Jason

FWIW, I am seeing the same issue with throwing the exception. I suspect it has something to do with the fact that I'm using the "main.php" templating approach, as the first error I saw was from trying to redeclare a function that only appears at the top of main.php. Wrapping that in a function_exists() conditional results in a different error, at the point where I'm including the view for the current page: ob_start(); include('./views/'.$view.'/'.$view.'.inc'); // 404's error on this line now $layout = ob_get_clean(); ob_start(); include('./views/base/base.inc'); $template = ob_get_clean(); echo $template; Redirecting to the 404 page is (arguably) better than nothing, but ideally you'd just return a 404 status code directly on the originally requested URL.

Yes, I was looking for a solution that would allow the user to vary the percentages on a case-by-case basis. Currently working around it with Hanna Code, but wanted to make sure I wasn't missing a "native" configuration option.

Within CKEditor's default image properties dialog, you can set a percentage width on inline images and leave the height blank, which works better with responsive layouts. Within processwire's image manager (for CKEditor), it looks like you are limited to entering fixed pixel dimensions. Is there a config setting or module to change this behavior? It can be fixed manually by switching to source code view, but that's not very user-friendly. It can be overridden in CSS, but that's not as flexible. Thanks!

Aha. Missed that, thanks!

I get back an empty array, even if I take out the conditional filtering. Is this something that has to be configured to collect data?