1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Roadmap Version 1.8

Discussion in 'RoadMap' started by shibuya246, Dec 11, 2014.

  1. valMETNG

    valMETNG Administrator Staff Member Admin

    I'm curious: is there a reason why you used divs for submit2 but a table for submit_edit (i.e., why not make them look the same)?
     
  2. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    sure looks odd. we dont have memcache running yet so the levels of caching are

    1. none at all - full db queries every page load
    2. cache to the session var- only is good for each user. at the moment we are caching the currentUser data only. no point in caching plugin hooks, site settings for every user each time. that is the job of memcache, redis etc - or the db
    3. we do have a few file db caches that are used storing queries that are run

    on the top page with no posts i cant think why there would be 100 queries except possibly .... . . . . . . and this needs fixing, the initial startup may be calling the forum site to check the version numbers of plugins and i will have to check but it might be saving them individually one by one as opposed to a bulk update. i will check that. this could be the reason for it and needs fixing if so. the 100 queries would not refer to the posts,user, site settings, theme settings, plugins etc. 100 is just way too much.
     
  3. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    my guess would be i edited the files at different times, but it is possible there was something on edit that didnt sit right with the divs maybe on a plugin hook from a different plugin and i made it a table instead just to get the v1.7 out. happy to move it to divs
     
  4. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    fixed up the "page not found" error on browse users, and also tweaked the query there to not include killspammed members. fixed the label colors also

    i am planning a v1.7.1 next week although the changes are not security issues or highly critical. just small items that would be nice to have cleaned up on everyones sites. will try to get all the points you have found covered in that also.

    I will look into the first time startup query problem as well
     
  5. valMETNG

    valMETNG Administrator Staff Member Admin

    On line 328 in user_manager/user_manager_settings.php, it won't affect functionality but I believe you used the old $h->displayTemplate instead of $h->template.
     
    shibuya246 likes this.
  6. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

  7. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    thanks. i will go through code and replace all of those in the core to be just template
     
  8. valMETNG

    valMETNG Administrator Staff Member Admin

    It's possible but doubtful I'll get through all the code by next week. I've decided to take a slightly different approach in reviewing the 1.7 code against my build in order to get feedback to you quicker: instead of reviewing/rethinking all my complicated, custom, spaghetti code relative to all of your excellent enhancements, I'm just looking for small/more obvious differences between code bases. My theory is this will require significantly less testing on my part to "upgrade," although my custom code base will still be radically different in many key areas.

    But I'm working on this as fast as I can :)
     
    shibuya246 likes this.
  9. valMETNG

    valMETNG Administrator Staff Member Admin

    Users use it on my site, so my preference is to leave it. You don't like the way it looks?
     
  10. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    ok, have changed on all core plugins and also on some 3rd party ones
     
  11. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    there was a request to make the user profile page full width rather than have the sidebar showing.

    not sure whether people like the sidebar being there or not. I would like to improve the user profile pages to make them more interesting, bring them alive a bit
     
  12. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    I may end up taking 2 weeks :)
     
    valMETNG likes this.
  13. valMETNG

    valMETNG Administrator Staff Member Admin

    LOL. You see? By giving me this out, you're giving me breathing room to not work as hard. :)
     
  14. shibuya246

    shibuya246 Hotaru Developer Staff Member Admin

    The deadline just got moved up to this Wednesday :)
     
    valMETNG likes this.
  15. valMETNG

    valMETNG Administrator Staff Member Admin

    According to http://www.w3schools.com/tags/tag_label.asp, the for attribute of the <label> tag should be equal to the id attribute of the related element to bind them together. You might want to check if all 1.7's label tags work like this. For example, I noticed a few of these in user_signin/templates/user_signin_register.php:
    Code:
    <label for="registerusername"><?php echo $h->lang["user_signin_register_username"]; ?></label>
      <input type='text' class="form-control" name='username' value='<?php echo $username_check; ?>' />
    
     
    shibuya246 likes this.
  16. valMETNG

    valMETNG Administrator Staff Member Admin

    In user_signin/user_signin.php, cookies (e.g., line 96) are set as "hotaru_user" and "hotaru_key." In my environment, I have multiple builds (e.g., base, development, alpha, beta, production). This makes it difficult for me to use the same browser when testing how code works in different builds because the cookies aren't differentiated. My suggestion would be to put something in admin settings that allows you to specifically define what the cookie name begins with (i.e., instead of "hotaru"). To get around this, in my build, I did this after the $parsed definition (but it's not the ideal solution):
    Code:
    $cookie = str_replace(array('/', '.'), array('_', '_'), $parsed['host'] . $parsed['path']);
    setcookie($cookie . "_user", "", time()-3600, "/", "." . $parsed['host']);
    setcookie($cookie . "_key", "", time()-3600, "/", "." . $parsed['host']);
    Something to consider for future versions.
     
    shibuya246 likes this.
  17. valMETNG

    valMETNG Administrator Staff Member Admin

    All through hotaru, emails are hard-coded. For example, this is what we see in user_signin/user_signin.php:
    Code:
      // send email
      $subject = $h->lang['user_signin_register_emailconf_subject'];
      $body = $h->lang['user_signin_register_emailconf_body_hello'] . " " . $user->name;
      $body .= $line_break;
      $body .= $h->lang['user_signin_register_emailconf_body_welcome'];
      $body .= $line_break;
      $body .= $h->lang['user_signin_register_emailconf_body_click'];
      $body .= $line_break;
      $link = BASEURL . "index.php?page=emailconf&plugin=users&id=" . $user->id . "&conf=" . $email_conf;
      $body .= "<a href='" . $link . "'>" . $link . "</a>";
      $body .= $line_break;
      $body .= $h->lang['user_signin_register_emailconf_body_regards'];
      $body .= $next_line;
      $body .= $h->lang['user_signin_register_emailconf_body_sign'];
      $to = $user->email;
    This makes it difficult for a non-technical user to format the way the emails look. It would be useful to have an editor whereby an admin could maintain templates for the various emails that hotaru sends. When emails are sent, the code would then look for specific tags (e.g., {username}, {password}) and replace those with the appropriate values. This would allow admins an easier way to make emails received from the site look pretty without having to modify core code.

    Another alternative (but one that requires admins to be a bit more technical) would be to pull this code out of core and/or plugins and into templates. You could even have templates like "top_template" and "bottom_template" where an admin could standardize on the look, with the "middle_template" being specific to the types of email (e.g., new message, register confirmation, new comment). You could also allow for specific .css based on type of email.

    Something to consider for future versions, especially given communications from the site that don't look professional somewhat detract from your marketing image/efforts.
     
    robin007 and shibuya246 like this.
  18. valMETNG

    valMETNG Administrator Staff Member Admin

    On lines 57-58 of users/templates/users_edit_profile.php, I'm noticing table tags without a table:
    Code:
      <?php echo $h->lang["users_profile_edit_bio"]; ?>&nbsp; </td>
      <textarea class="form-control" rows=5 name='bio'><?php echo $profile['bio']; ?></textarea></td>
    Probably just left behind by accident.
     
  19. valMETNG

    valMETNG Administrator Staff Member Admin

    Considering how much javascript is used, may I suggest including something like this in index.php (and the language file of course) after the <body> tag?
    Code:
      <noscript>
         <div id="no_javascript">
           <strong><?php echo $h->lang('javascript_disabled'); ?></strong>
         </div>
       </noscript>
     
    shibuya246 likes this.
  20. valMETNG

    valMETNG Administrator Staff Member Admin

    I'm curious: what is the purpose of this modal at the end of index.php?

    Code:
      <div id="myModal" class="modal fade bs-example-modal-lg" tabindex="-1" role="dialog" aria-labelledby="myLargeModalLabel" aria-hidden="true">
      <div class="modal-dialog modal-lg">
      <div class="modal-content">
      <div class="modal-header">
      <button type="button" class="close" data-dismiss="modal"><span aria-hidden="true">×</span><span class="sr-only">Close</span></button>
      <h4 class="modal-title" id="myLargeModalLabel">Modal</h4>
      </div>
      <div class="modal-body">
      ...
      </div>
      </div>
      </div>
      </div>
     

Share This Page