Jump to content

Jason Huck

  • Content Count

  • Joined

  • Last visited

Posts posted by Jason Huck

  1. Just to follow up, I discovered that there was no entry in the fieldgroups_field table linking the missing field to the admin template. I manually added a record there, re-saved my custom page, and now it's working as expected.

    I am concerned about how the db got into this state in the first place, but I don't think this module is to blame.




  2. I have used this module successfully in the past, but am having trouble getting it to work properly in PW 3.0.123.

    The module installs without error and I can create an admin page (using the admin template and the correct "Process."), but the FieldTypeAdminCustomPagesSelect field never shows up on the page. (The field is defined in the fields table.) I manually entered a value in field_acp_template to try and circumvent the issue, but it's not finding the template file.

    What else should I check? Any ideas?



  3. My company is hiring two full time positions that might be of interest to members of this forum as we build out our UX team. Among other things, we will be migrating a number of sites over to ProcessWire, developing a UI pattern library, and establishing a continuous improvement process for them. Lots of front end work but also some API development, PDF generation, and other fun stuff. These are multilingual sites (currently English, German, and Chinese, more languages to come) for a global company, but these positions are on site in our Cincinnati, Ohio corporate HQ. For more information, or to apply, see the following links:

    Web Developer

    Digital Designer



    • Like 6

  4. Also:

    - The host uses both nginx and varnish in front of Apache. I do not have access to the nginx config, and only realized it was in the mix by inspecting the response headers from the server.

    - The host also uses varnish. I have access to a varnish folder, the only contents of which is a text file where you can exclude domains from caching. I added the domains for this host, but I still see varnish headers in the response. The response is a "miss", though, so I don't think caching is an issue.

    - ProcessWire is fielding the AJAX request and the code I have in place to handle it gets executed without (server-side) errors. It subscribes the user to a MailChimp mailing list (verified at Mailchimp), sets a cookie, and returns a JSON response.

    - Even though setcookie returns 1, the cookie doesn't get set in my browser. The standard PW cookies do get set, though.

    I've tried explicitly setting various access control headers in .htaccess, but it's not a cross-origin request. My best guess currently is that nginx and/or varnish have security settings which are interfering. I've asked the provider for assistance but haven't had much luck yet.


  5. Trying to deploy a PW site to a client's hosting provider. Everything works as expected in development, but on the production host, certain AJAX requests fail. Here's what I'm seeing:

    1) I have form on every page which is submitted via AJAX POST to the current page. No matter which page you POST to, it always returns a PW 404 page.

    2) AJAX image uploads on the back end return a 200 or 302 for the original request, then spawn a GET request for the homepage.

    In trying to troubleshoot this, I have found that the host has both suhosin and mod_security installed. They've provided me with a local php.ini to test configuration changes. I've added the following to .htaccess (temporarily):

    # account-specific php.ini file
    <IfModule mod_suphp.c>
    	suPHP_ConfigPath /home/[username]
    	<Files php.ini>
    		order allow,deny
    		deny from all
    # disable mod_security
    <IfModule mod_security.c>
    	SecFilterEngine Off
    	SecFilterScanPOST Off

    In the php.ini file, I've set the following directives:

    suhosin.simulation = On
    always_populate_raw_post_data = -1

    I've also set a specific directory for uploads:

    upload_tmp_dir = /home/[username]/tmp

    GD support is included.

    PW doesn't log any errors, even with $config->debug set to true.

    This is PW 2.7.3 on PHP 5.6.28.


    What else should I check?



  6. 6 minutes ago, kongondo said:


    1. WireCache: Create a natural sort field, say nat_sort. Have this hidden; we don't need to see it in the admin. Add that to the template of the pages you need to sort naturally + paginate (let's call the template 'nat-sort-pages'). Create your Hook and add a function that will build/refresh a non-expiring Wire Cache every time a page that uses 'nat-sort-pages' template is created (no need to do this when the page is edited; just when added). The cache will save the new page's ID, Title (the field to naturally sort) and a 'nat_sort' value of 0 (or whatever your starting index is; here we also assume this is the first page created). Subsequently, when another page is added, your Hook will retrieve the cache, add the details of the new page to the array, use PHP natsort() to sort that array (by Title) + change the values of nat_sort within the array, save it back to the Wire Cache, then use SQL to insert the values in your nat_sort field. Your nat_sort field will be an integer field, so you SQL (pseudo code) will INSERT nat_sort_value IN nat_sort WHERE id=page->id. That should be a very fast operation. In the frontend, use a find sorted by your 'nat_sort' field (sort=nat_sort in the selector) to retrieve paginated results.
    2. getById() + SQL nat sort: This approach does not require a nat_sort field nor a Hook. It is an on-demand method for use in the frontend. Use a suitable SQL workaround to naturally sort a limited number of results (i.e. see links above + you'll need to use SQL LIMIT and START). Your SQL will only need to fetch the IDs of those pages. Then use getById (see example here) to retrieve those pages, which you then pass on to your pagination.


    Option 1 is more or less what I assumed I would have to do. My data set is around 560 pages, and they are all created/updated in bulk via a custom import script, so I may end up just populating the natural sort field as part of that routine.

    Option 2 isn't really an option in this case, because the contents of my sort field are highly irregular, and those SQL tricks rely on the sort field containing strings of predictable length and/or composition.

    Thanks for the input -- I wanted to be sure I wasn't missing something in the API.


  7. 1 hour ago, adrian said:

    It seems to me that PW's sort() could support PHP's sort_flags - then you could specify something like:

    $pages->find($selector)->sort("fieldToSortBy", NATURAL_SORT);

    I just did a quick hack of WireArray.php and on first glance it all seems to work fine. The NATURAL_SORT flag does require PHP 5.4.


    That would be a nice addition, though in my particular use case, I think I'd need support within the selector itself, e.g. something like one of these:

    $pages->find('...etc...,sort=title', ['sortmethod' => NATURAL_SORT]);

    ...otherwise, I'd only be sorting the returned PageArray, and not the entire set, so it couldn't be used for pagination.

    • Like 1

  8. Whether truly at the database level or not, I was hoping there was a built-in PW method to apply that sorting algorithm. Otherwise I will probably have to create a separate field just for sorting, and add a hook when new pages are created that retrieves the entire result set, sorts it manually, and updates that field with each page's position in the entire set. That's the only way I can think of that will allow me to later retrieve a filtered subset that remains in the correct order. If there's another approach I should consider, I'm all ears.




  9. What's the easiest way to retrieve a PageArray -- with an offset and a limit, for use in paginated search results -- that is sorted by title using PHP's SORT_NATURAL instead of alphabetically? I was hoping there was a config setting or API method that would handle it for me, but if there is, I haven't stumbled across it yet.

  10. Anybody know if there's a way to set upvotes and downvotes via the API? I'm not using the voting features, but I'm importing a nested comment structure and thought I would temporarily use those fields to store legacy IDs. I tried the expected $c->upvotes = $value, both before and after save, but they don't get stored in the database.


  11. Actually I can't get this working even in PW 2.7.x. When I tried to install it, I got the following untrapped, fatal error:

    Error: Class 'WebmentionItem' not found (line 78 of [path to webroot]/site/modules/Webmention/ProcessWebmentionsManager/ProcessWebmentionsManager.module)

    I manually removed the Webmention folder from the modules folder and refreshed modules. Now if I put the folder back, I get an ISE, and this error is logged:

    Error: Class 'ProcessWebmentionsManager' not found (line 407 of [path to webroot]/wire/core/Modules.php)

    Suggestions welcome.

  12. I had to set this project aside for a while, but recently came back to it. In the meantime, I had upgraded the site to PW 3.x and had hopes that this issue would magically disappear. It didn't, and subsequent attempts to further optimize the import routine didn't help.

    At the moment, though, I can consistently eliminate the timeouts by temporarily enabling debug mode while performing the import, e.g.:

    $config->debug = true;
    $import = importProductData($filepath);
    $config->debug = false;

    I have no idea why this works, but so far, it does. I'll have to see if the timeouts return if the data set gets larger, but it's already quite a bit larger than it was back in August when I was last working on it.

  13. 3 hours ago, Lance O. said:

    Is there a way to force "www" on the links generated in the sitemap.xml file?

    Your web server should be configured to have a single canonical domain to avoid fragmentation of SEO and analytics, and your sitemap should use it. If the "www" version of the domain is canonical, requests for sitemap.xml will be redirected to that domain and the generated links should match. The module simply uses the value of $page->httpUrl. ProcessWire's .htaccess file includes directives for Apache to set a canonical domain, but they are commented out by default. Look around line 123:

      # -----------------------------------------------------------------------------------------------
      # 13. OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable).
      # For example: http://processwire.com/ would be redirected to http://www.processwire.com/
      # -----------------------------------------------------------------------------------------------
      # RewriteCond %{HTTP_HOST} !^www\. [NC]
      # RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]


    • Like 3

  14. 2 minutes ago, Mike Rockett said:

    Also true... Perhaps I should then default it to the ext parameter type then?

    Makes sense to use the same list for both purposes, as long as it's configurable. For instance, in a current project we have to handle requests for .pdf files that are now served via a PW-powered download page.

  15. 7 minutes ago, Mike Rockett said:

    Regarding the first one, perhaps those options should become unavailable the second the question mark is entered?

    How would you distinguish between a literal question mark and its current use to make the previous character optional? Would it have to be escaped, or is that syntax changing in v2?


    9 minutes ago, Mike Rockett said:

    I did think about that second one, but didn't think about filtering extensions. Perhaps a simple check for \.([a-z0-9-]{3,5})...?

    I configurable list of allowed extensions would ultimately be safer and more flexible. People create all sorts of crazy URLs, and we don't know what someone might need to allow/disallow.


  16. 17 hours ago, Mike Rockett said:

    Yeah, it can be quite a tough subject - but a checkbox should cover it well-enough. That said, do we trim out any included query string so it does not get matched if the checkbox is selected?

    Perhaps two options when creating a new rule:

    [x] Source URL may include a query string.
        [x] Append query string to target URL.

    You would only use these options if you did not need to match on the contents of the query string or use it to determine the correct target URL.


    18 hours ago, Mike Rockett said:

    This is a good idea, but I can imagine some would want a little control over it. Perhaps a global strict mode for trailing slashes (off by default, allowing both to match)?

    Perhaps global options like so:

    [x] Trailing slash is optional for source URLs which do not end with the following extensions:
        [.html, .htm, .php, .aspx, .cfml, .pdf ...]

    I suppose you could include the ability to override at the rule level, but would it even be necessary?


  17. On 11/14/2015 at 0:04 AM, Mike Rockett said:

    In the discussion, I mentioned there would either be a checkbox in the entity editor that allows you to make query strings optional, or that we could use square parenthises to mark them as optional, like this: bioh[?gclid={token:any}].

    An option to automatically pass along (but otherwise not match on) query strings would be ideal. I'm seeing a lot of automatically appended tracking codes breaking rules. For example:


    For now, I assume i can do this:


    ...or even:


    ...to zap any query string, but poor HootSuite won't get credit for the referral. Tough point to cover when training non-technical administrators to use the module, though.


    A configuration option to automatically assume trailing slashes are optional would also be very handy, for the same reason. That way admins wouldn't have to remember to append ? to the end of every source URL.


    Another issue is that source URLs are URL encoded when stored, even if the actual source wasn't. So for example, if the source URL contains an unencoded comma and/or ampersand:


    ...it gets stored like this:


    ...which, while corrected, is not the actual source URL, so it doesn't match.



  18. In case anyone finds this thread because they're deploying a project started in PW2.7 or older to a ServerPilot-managed container (in which case, just updating the schema isn't sufficient, as many records may have been created with invalid values), ServerPilot recommends creating a separate .cnf file to disable sql strict mode:


    Don't just copy and paste that configuration, though. The specific items that need to be removed are NO_ZERO_IN_DATE and NO_ZERO_DATE.

    Creating a separate .cnf file for your customizations will avoid them being overwritten by automated ServerPilot updates.

    • Like 2

  19. Whoops, my bad. I had read this: http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-selectorvalue-value/

    ...combined with this: http://processwire.com/api/selectors/#sanitizing

    ...and spotted this: https://github.com/processwire/processwire/blob/master/wire/core/Sanitizer.php#L1506

    ...and since searches containing dashes weren't working in this project, had come to the conclusion that $sanitizer->selectorValue() considered dashes to be illegal characters and was replacing them with spaces, but that's clearly not the case.

    I've since discovered that dashes are ignored characters by default in the Indexer module, which is what I'm using for search. I've taken that character out of the Ignored Characters field and reindexed all objects, but still not getting results. Most likely some old results are cached somewhere. I'll verify dashes are actually present in the indexer field, and take it from there. Thanks for the clarification!


  20. Am I right in understanding that there's no way to escape or encode a dash ("-") for use within a selector value (that has to be sanitized)? Looking at the code for $sanitizer it looks like it's just converted to a space. That seemingly makes it impossible to search for terms like "x-ray." Any workarounds for this?

  • Create New...