• Content count

  • Joined

  • Last visited

  • Days Won


thetuningspoon last won the day on May 8 2015

thetuningspoon had the most liked content!

Community Reputation

379 Excellent

1 Follower

About thetuningspoon

  • Rank
    Hero Member
  • Birthday 11/03/1986

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    CT, USA
  • Interests
    Design, Programming, Tiny Houses

Recent Profile Visitors

11,095 profile views
  1. I'm working on an application in ProcessWire which allows users to have their own publicly accessible storefronts. I'm struggling to figure out how this should be represented in the URL/page tree. The ideal finished product would put the user's storefront at a unique url like The cart, checkout, and products pages would follow the same structure: And so on... The problem is that I don't want to have to create a whole new section of the page tree for each new user. So, in effect, I want a url segment (the /username/ bit) that appears before the page name rather than after it. As far as I know, this isn't possible in PW. Another approach would be to use a query string variable to identify the user (e.g. ). This solves the problem of having to create a different tree for every user, but the URL is not nearly as convenient for customers, and it would require passing the parameter through all of my links. I suppose I could use query string parameters but then provide a more friendly URL to redirect there, but that doesn't feel quite right to me either. Anyway, I'm sort of thinking out loud here. Any other ideas?
  2. @Robin S Good call on using addslashes(). Is there a reason why this wouldn't work for the exact match operator (=) ?
  3. I know this is an old thread, but I ran into a similar issue today. I was trying to select a row in a profields Table by the contents of its text field, but selectorValue() was stripping out the "#" character from the selector value, preventing the match from being found. I had always sort of assumed that selectorValue just escaped the value to make it safe for a selector, without actually altering the value. But now I see that this isn't the case (and it also limits the length to 100 characters by default). It looks like the only way to achieve what I'm looking to do is to strip out double quotes from within the input string that I get and then wrap the whole string in double quotes (as Ryan describes above). If I understand correctly, this would be a safe way to escape the input. The only problem with this is that double quotes then cannot be used in the text field, which could be an issue. Is there any way to create a safe selector that can handle double quotes in addition to commas, hashes, and the other characters that selectorValue() strips out?
  4. Got it. It's working great!
  5. @Robin S Yeah, that makes sense. Just tested the previous build and found that it is still stripping out the long text inputs after re-saving them. Did you resolve this in your latest update?
  6. @Robin S Great, I'll try it out. Does this also mean that textareas are a configurable input type now? That was a feature I was going to request.
  7. The close button is working now, but opening an existing code now shows a completely blank iframe in the popup. PW version is 3.0.40. Hanna code is 0.2.0 Edit: No console errors, either.
  8. Hi Robin, Great module. Is the module dialog supposed to allow you to edit existing Hanna Codes? When I double click an existing code, it opens in the dialog but none of the inputs are filled out. If I save, then all of the content disappears. Another issue I ran into after upgrading to the latest build: The cancel button on the dialog no longer works. The JS error I'm getting is: "hannadialog.js?t=2015030801.157:32 Uncaught TypeError: Cannot read property 'setAttribute' of null"
  9. YES. YES. YES. I can't wait to try this on my latest project
  10. Hmm... But #2 isn't required, it's only one of the conditions under which the file access will be blocked, so I still don't get it. I think I will post on GitHub.
  11. Thanks very much, Kixe. Good call on the before hook. Maybe you can help me better my own understanding of the situation... I guess I am still not understanding a piece of the puzzle here. Consider the following: $config->pagefileSecure is set to true Page::isPublic() returns false User is not logged in If all 3 of the above are true, the file should not be directly accessible... correct? This is how PW behaves normally, with no need to hook ProcessPageView::sendFile(). Yet when all of the above is true except that Page::isPublic() was modified by a hook, suddenly it doesn't work as expected. There must be some other requirement that isn't being met, since this functionality doesn't normally require hooking sendFile(). See what I'm getting at?
  12. Why does sendFile() send the file even if isPublic() is false?
  13. Right, except that it doesn't - This is the part that isn't working right. Are you saying that the prefix would be removed after saving the page? I thought that it would be added after saving the page. Why would the directory be renamed as long as isPublic() continues to return the same value?
  14. I don't actually want to replace the method entirely, just change the result under some circumstances. But the hook clearly is working, it just doesn't look like it's running early enough, perhaps. Thanks for the debugger suggestion... I am working on getting a proper debug setup going.
  15. @kixe In your ProcessPageView::sendFile hook, are you checking Page::isPublic first? The way you have written it, it would block all files. Should I submit a report on GitHub? It seems like the isPublic hook should be enough to make this work. I don't understand why it isn't honoring it. Edit: Does sendFile() actually get called when a file in the assets folder is accessed directly?