Jump to content

ryan

Administrators
  • Posts

    16,430
  • Joined

  • Last visited

  • Days Won

    1,448

Community Answers

  1. ryan's post in Set checkbox to checked in admin was marked as the answer   
    I don't understand the code example well enough. But I'm thinking maybe you are intending to do something like this?
    $c->recipients = $input->post->recipients;  While that would work, it would be better to do some thorough validation, like this:
    $c->recipients->removeAll(); foreach($input->post->recipients as $id) {   $recipient = $pages->get((int) $id);    if($recipient->id && $recipient->template->name == 'recipient') {     $c->recipients->add($recipient);    } } 
  2. ryan's post in rename users was marked as the answer   
    You can make up your own users system, and sometimes it's the simplest route to achieve something. But I would try to get it done with regular PW users first. You can always map fictional page names to usernames via URL segments. For instance, if you had a template called 'riders' and you enabled 'URL segments' in the 'URLs' tab of your template, then your /site/templates/riders.php file could have code like this:
    if($input->urlSegment1) {   $rider = $users->get("name=$input->urlSegment1");   if(!$rider->id || !$rider->hasRole("rider")) throw new Wire404Exception("Unknown rider");      // display rider   echo "<h1>$rider->name</h1>";   echo $rider->body; // ...or whatever fields you wanted to output } else {   // display list of riders   foreach($users as $rider) {     if(!$rider->hasRole("rider")) continue;      echo "<li><a href='./$rider->name/'>$rider->name</a></li>";   } }
  3. ryan's post in Admin HTML title to include domain was marked as the answer   
    Already done
  4. ryan's post in Can't log in: "This request was aborted because it appears to be forged." was marked as the answer   
    This may be a problem related to ProcessWire wanting to use files for sessions and your server configured to use memcached, at least that's what the error message seems to indicate. The dev branch version has detection for this, so you might try switching to the PW dev branch and seeing if that fixes the issue for you (I'm guessing it will). Or if you want to quickly test it, just grab the index.php from the dev branch and replace the one in your installation. 
  5. ryan's post in Wikimedia commons-like images was marked as the answer   
    First question would be why not just link to the page rather than the image in the first place? But thinking on it more, I'm betting you are inserting these from TinyMCE/CKEditor? Something like this might work:
    function replaceImagesWithPages($str) { $rx = '{href="' . wire('config')->urls->root . 'site/assets/files/(\d+)/.+?"}i';   if(!preg_match_all($rx, $str, $matches)) return $str;   foreach($matches[1] as $key => $id) {     $page = wire('pages')->get((int) $id);      if($page->viewable()) {       $str = str_replace($matches[0][$key], "href='$page->url'", $str);      }   }   return $str;  } echo replaceImagesWithPages($page->body);    This type of thing could be bundled into your own Textformatter module for easy re-usability (let me know if I can elaborate). Note that this was written in the browser and not actually tested, so may likely need adjustments. 
  6. ryan's post in Switch from ssl to non-ssl in frontend does not work anymore was marked as the answer   
    In your /site/config.php file, you'll want to set a whitelist of allowed hosts. This was just added in 2.3.9 and it's a recommended security optimization. Include both your SSL and non-SSL host names in there. Please let me know if this resolves the issue you are experiencing?
  7. ryan's post in Custom validation for Repeater was marked as the answer   
    One of the next items on the to-do list for repeaters it to be able to specify a max number of items, but I'm not sure that would accomplish what you are looking for here. Your best bet may be a hook after ProcessPageEdit::processInput to look at the values of both fields. I would suggest setting your repeater "ready" items at 0, so that it is less to consider when counting the values. You could put this, or something like it at the top in your /site/templates/admin.php file:
    <?php wire()->addHookAfter('ProcessPageEdit::processInput', null, 'checkRepeaterQuantity');  function checkRepeaterQuantity($event) {   $form = $event->arguments(0);   // ProcessPageEdit's processInput function may go recursive, so we want to skip   // the instances where it does that by checking the second argument named "level"   $level = $event->arguments(1);   if($level > 0) return;    $select  = $form->get("your_quantity_select_field");   if(!$select) return;   $quantity = $select->attr('value');    $repeater = $form->get("your_repeater_field");    if(!$repeater) return;   if(count($repeater) > $quantity) {     $repeater->error("You have specified more than $quantity items");    } }  
  8. ryan's post in [Probably daft] performance question: _init.php Vs. config.php for vars was marked as the answer   
    This is a good way to go, and exactly what I do for predefined settings like required image dimensions and such. 
    What you set in _init.php is for runtime use of your site's template files, and probably nothing beyond that. These variables are good for initializing placeholders that you'll be outputting in your _main.php (or whatever your appendTemplateFIle is called). 
    This sounds like overkill to me, though of course use what works best for you. But you have a couple more options to consider:
    Use session variables, especially when you want the value to still be present and available on not just the current request, but subsequent ones (from the same user) too: 
    // do this  $session->set('my_variable', 'my_value');  // then retrieve it from anywhere (and at any later request) like this:  $my_value = $session->get('my_variable');   Set an API variable:
    // do this wire('my_variable', 'my_value');  // then retrieve it from anywhere like this:  $my_value = wire('my_variable');  Whichever route you take there, if you've got a lot of related values to set you might want to bundle them all into an array, so that you only need to set 1 session, API or config variable. 
  9. ryan's post in $user-hasRole() returns sometimes true, sometimes false? was marked as the answer   
    If there was a way for us to make PW automatically reassign the $user variable after login, we'd do it. It's not technically possible for PW to do that (it's a matter of variable scope). That's why you'd have to do what Adrian suggested and assign the $user variable yourself from the result of login(). However, what Soma was getting at before he gave up was even better because it wouldn't trash the $user variable if the login failed. So something like this might be ideal:
    $u = $session->login($username, $pass);  if($u) {   $user = $u;   echo "logged in"; }
  10. ryan's post in Cannot get() a page by path if it ends with "pageN" was marked as the answer   
    That's because the "page10" portion is not part of the page's path in the system. It's just an extra instruction to the page, like a URL segment, telling it to use the 10th pagination. In this case, you'd want to trim off that "page[n]" portion. There's any number of ways to do that, but I'd probably just use a regex: 
    $title = 'http://host/gallery/page3'; $title = preg_replace('{page[\d+]/?$}', '', $title);  echo $title; // should output "http://host/gallery/"
  11. ryan's post in rename() convention for duplicate files was marked as the answer   
    I think that this change should be okay, I can't think of any potential side effects here. I make the same change here–thanks!
  12. ryan's post in File Upload Location was marked as the answer   
    Files uploaded to pages go in /site/assets/files/. Files uploaded to FormBuilder forms go in /site/assets/cache/form-builder/ (or another directory, which you can define in your FormBuilder module settings). If you've got a file that's going in both, then that would be because you've got FormBuilder publishing entries to pages. I don't recommend automatically publishing entries to pages–better to approve them individually before publishing to pages. But either way, if you are publishing entries to pages, then there's going to be a file associated with the entry and another associated with the page. If form submissions are being used for the purpose of publishing to pages, then typically you'd delete the entry after publishing it to a page (thereby deleting the original copy of the file too). Let me know if I've misunderstood the question?
  13. ryan's post in Template File as Controller - How to access $input, $user, etc. was marked as the answer   
    Your simplest best would be to just extend ProcessWire most basic starting point, which is Wire. This enables your class to have access to API variables (through $this), enables any of your methods to be hookable (that you precede with 3 underscores), and makes the file possible to translate with language support. 
    Another option is to extend WireData. This is the same as Wire, except that you gain $this->set() and $this->get() methods that are accessible both in and outside of the class. It essentially means your class can function as a shared data container. The set() and get() can also be accessed by $this->key = 'value'; and $value = $this->key. 
    The last utility class to mention would be WireArray, which is meant for storing an array of objects. This one is a little more complex than the other two (though it's still quite simple), and I'm guessing it's not what you need in this case, so won't go into detail unless you want me to. 
    You don't necessarily have to extend any of PW's classes. But if you want $this->property; access to the API variables, you'd want to implement your own __get() method in your class:
    public function __get($property) {   return wire($property);  // or Wire::getFuel($property); }
  14. ryan's post in Saving Textarea fields with HTML tags: sanitizer & escaping questions was marked as the answer   
    If you are populating this data to a PW textarea field, then it's going to take care of ensuring the data is sanitized for storage in the DB. You don't need to do that. However, what you need to be concerned about is outputting that data. That data could contain stuff that may be perfectly safe for DB storage, but is full of XSS when presented to the user. If you need to allow markup from untrusted users, your best bet is to sanitize with HTML Purifier. We also have a MarkupHTMLPurifier module for ProcessWire. You would simply run it through HTML Purifier before populating to the PW page field, and that would have the effect of removing markup which could be considered problematic or insecure.
    Another alternative is to use a restricted LML, like Textile Restricted or BBCode. But of course your users would have to use that LML rather than HTML, which may or may not be desirable.
  15. ryan's post in Translation permission for editors was marked as the answer   
    The language translation tools are intended to be admin-only, so assigning permissions for that isn't supported by default. There are potential security implications with making it a default/supported capability. But it is something you could add relatively easily by editing the ProcessLanguage.module and ProcessLanguageTranslator.module files located in /wire/modules/LanguageSupport/. In the getModuleInfo() function of each, you'd want to add a 'permission' line, like this:
    static public function getModuleInfo() {   return array(     'title' => __('Languages', __FILE__),     'version' => 100,     'summary' => __('Manage system languages', __FILE__),     'author' => 'Ryan Cramer',     'requires' => 'LanguageSupport',     'permission' => 'language-edit' // ADD THIS LINE     ); }  Then in your admin, go to Access > Permissions and add a new permission called "language-edit". Give that permission to any roles you want to be able to use these tools. 
  16. ryan's post in possibly messed up the 404 handler? was marked as the answer   
    I'm really curious to know where that tools.php is coming from. If you edit your /http404/ page, what template is it using? Is your site based on an existing profile? 
  17. ryan's post in Safely ignore which folders when copying a site? was marked as the answer   
    I don't personally exclude anything when migrating a site from dev to live. While it might make sense to exclude things like /site/assets/cache/ and /site/assets/sessions/, it's also not entirely necessary as those things are already under automatic garbage collection/clearing. You do need to make sure that those directories exist though. So if you exclude them from the copy, double check that the directory still gets created. I see no problem with excluding those directories (and /site/assets/logs/ if you want to) as long as you make sure they get re-created in the destination and are writable to PW. 
  18. ryan's post in Modifying the Admin Users List was marked as the answer   
    Arcturus,
    Go to Modules > Process > Users. It should let you select what fields you want to be shown in the listing, and in what order.
    As for changing the name of the "name", I don't think you can do that short of going through a hook or using the multi-language translation system (and translating the default language value). If you want to do that, the file where it is located is /wire/modules/Process/ProcessPageType/ProcessPageType.module in the renderList() method. Of course, you could just change it directly in that file, but your change would get overwritten during upgrades, so you'd need to remember to change it again. 
  19. ryan's post in Greater than today was marked as the answer   
    "today" is something you could use within a ProcessWire selector, like below (so long as you are querying a datetime field): 
    $garagesales = $pages->find("town_select=$town, Date>today, sort=-Date"); …but it's not a PHP language construct, so you couldn't do this:
    if($c->Date>today) {  Like maba mentioned, you'd want to use the time() function instead, which returns the current unix timestamp. You'd also want to retrieve the "unformatted" version of "Date", as you may have it configured to output a date string rather than a unix timestamp. And you'd nee the unix timestamp (which is an integer) in order to properly compare it with time(): 
    if($c->getUnformatted('Date') > time()) {
  20. ryan's post in Accessing PageTitleLanguage when bootstrapped was marked as the answer   
    You might want to move this into a PW template file (the exact code, minus the require_once at the top). This would ensure things are output formatted and you can take advantage of PW determining the language for you and such. Though the way you are doing it is just fine, but since you are bootstrapping PW output formatting is not enabled by default. You can enable output formatting for your $affiliate pages, so that you are dealing with formatted values. In your case, that would mean $title would be a string rather than an object. 
    $affiliate->of(true);  You may also want to add a header before outputting your JSON:
    header("Content-Type: application/json"); 
  21. ryan's post in setMarkup() does not work for Radio buttons (InputfieldRadios) was marked as the answer   
    The setMarkup() is just for adjusting the markup of Inputfield lists, not the markup of individual Inputfields. That markup is not currently changeable programatically. Your best bet would be to either:
    1) the clean way would be to make a copy of InputfieldRadios => InputfieldRadiosCustom, install as a new module and make it produce the markup you want.
    2) the quick n' dirty way would be to replace the <li>'s with <div>'s by hooking after InputfieldRadios::render
    wire()->addHookAfter('InputfieldRadios::render', function(HookEvent $e) {   $e->return = str_replace( array('<li ', '</li>'), array('<div ', '</div>'), $e->return);  }); 
  22. ryan's post in Language for Login page was marked as the answer   
    While either of those solutions may work for this case, Radek's suggestion is the safer and recommended one. Your guest user is the default user when no user is logged in, so it's best to keep the guest language as the default. There is nothing about the default language that says it has to be English. You can make your default language whatever you want it to be. But the purpose of having a default language is exactly for situations like this. Plus it means you can code your templates in a manner that isn't dependent upon one language or another. 
  23. ryan's post in sessionhandlerdb not working on server was marked as the answer   
    Just to confirm, sessions are working (i.e. you are able to stay logged in consistently), but you just don't see anything in the Setup > Sessions page? Is it completely empty, or do you just see yourself there? In testing here, I can't seem to duplicate the issue. Double check the top drop-down box that lets you specify how many minutes you want to see sessions for. Make sure it is set to at least 5 minutes. If doesn't do it, try increasing it to 43200 minutes and see if that makes any difference?
    Another thing to double check is caching. If you are using ProCache, you will not see sessions appear here except when PW has to render the page. That's because ProCache bypasses sessions and the overhead associated with them. So not seeing sessions here would be expected and desirable, but only if using ProCache. 
    Last thing to look at is your Modules > Session > Session Handler DB module settings. Try enabling (or disabling) "track IP addresses" and/or "track user agent" in the settings, to see if it makes any difference. 
  24. ryan's post in FormTemplateProcessor adding user to post was marked as the answer   
    ProcessWire already keeps a references to the users that created the page and last modified the page, so you don't need to maintain that separately yourself. They are present in $page->created_users_id and $page->modified_users_id (to get the ID) or $page->createdUser and $page->modifiedUser to get the User objects. 
  25. ryan's post in Capitalized Cyrillic letters stripped out: a Sanitizer::translate bug? was marked as the answer   
    The mb_strtolower($text) isn't necessary in the above line, as when you specify Sanitizer::translate, that's already the first thing it does in the pageName function. 
    Take a look at the module settings in Modules > Inputfield > Page Name -- from here you can specify your own translation table for how characters should be translated. Is this what you are looking for, or something different?
×
×
  • Create New...