Jump to content

Jason Huck

  • Content Count

  • Joined

  • Last visited

Posts posted by Jason Huck

  1. 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!


  2. 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.

  3. 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.

  4. 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.

  5. 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:





    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...)?



  6. 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.

    • Like 1

  7. 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.

  8. 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:

        include('./views/'.$view.'/'.$view.'.inc'); // 404's error on this line now
        $layout = ob_get_clean();
        $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.

  9. 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.


  10. Is there an easy way to get back the SQL query generated by a specific processwire selector? I have what appears to be a cartesian product and/or groupwise maximum bug in a selector, but I'm not sure how to confirm it.

    I'm querying for a set of pages with a specific template which are related to the current page. The returned pages include a URL field and a file field. The selector looks like this:

    $grades = $pages->find('template=grade,include=all,classification.title="'.$page->title.'",sort=series,sort=title');

    "classification" is a page field. Series and title are text fields. I'm iterating through the results and outputting three text fields, a URL field, and a file (->url) field. On one of the nine pages using this query, it should only return one row, but it returns two. The text fields are identical for both rows. The URL and file fields are empty in the first row and populated in the second row. The other eight pages all work as expected with no duplication.


  11. I haven't read this thoroughly, so likely missing the point, but what about using the alternate template filename option from the Files tab for each template?

    Yes, that's exactly what I ended up doing. I just didn't realize that was an option until pwired provided the link to the other thread.

    • Like 1
  • Create New...