WordPress.org

Make WordPress Systems

Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Dion Hulse 12:26 pm on March 23, 2016 Permalink | | Unresolved
    • Dion Hulse marked this unresolved
      12:26 pm on March 23, 2016

    Tags: plugins trac,   

    #1641meta has pointed out that plugins.trac.wordpress.org is missing ~8400 changesets.

    Can we do something to import those missing changesets? As we’re running Trac with explicit synchronization, I think it might just be a case of running trac-admin changeset added for each of the missing revisions.

     
  • Dion Hulse 6:05 am on March 14, 2016 Permalink | | Unresolved
    • Dion Hulse marked this unresolved
      6:05 am on March 14, 2016

    Tags: ,   

    Removing the PHP 5.4 plugin directory linting

    The plugin directory has linting against PHP 5.4 for quite some time now. It used to be a feature to prevent accidental bad commits, but today it’s now regarded by many as a bug.

    We need to do one or more of the following:

    1. Upgrade the PHP linting to PHP-latest-stable (7.0)
    2. Upgrade the PHP linting to PHP 5.6 with a plan to move to PHP 7.0 (latest stable) and keep up with future releases
    3. Switch PHP linting to being a warning instead of a block
    4. Remove the linting all together

    Simply upgrading the linting to PHP 5.6 only kicks the can down the road, and still blocks people from using PHP 7 syntaxes in plugins (which is totally okay, if the plugin specifies that as a requirement).
    Removing the linting seems like a bad idea, as I believe authors should still be notified they’re committing code that may not be compatible (Unfortunately we currently don’t do php fatal error prevention checks on plugin upgrades, so I’d like to retain it to prevent an unexpected WSOD).

    So, I personally feel we should leave the linting at PHP 5.4 (which is what the majority of WordPress sites run today) and make it a warning, not a block.

    In order to warn instead of outright blocking, the linting needs to be moved from the pre-commit hook to the post-commit hook and the script exiting with a error-level code, STDERR will then be sent to the client after the commit is made.

     
    • Dion Hulse 6:09 am on March 14, 2016 Permalink | Log in to Reply

      I’ve posted a diff to Slack for #3 for review (posted there, as it contains not-public-items). I’ve partially tested it on a local SVN repo, but I don’t have all the same structures as the plugin directory.

      Ideally we should also remove the PHP 5.4-requirement for dotorg and meta SVN’s at the same time, or switch those to using PHP 5.6 / whatever is running web requests at the time.

    • Ipstenu (Mika Epstein) 9:53 pm on March 14, 2016 Permalink | Log in to Reply

      I know we email devs when they’ve uploaded a new version. Can this lint result be included in that email?

      I only ask because I want to be sure people get notified when they use various GUIs that are remarkably good at supressing/hiding alerts.

      • Dion Hulse 11:43 pm on March 14, 2016 Permalink | Log in to Reply

        I guess you mean the commit notifications?
        I’ve not tested any GUI tools, but do they really suppress the errors?

        It would be possible to email the lint failures to plugin devs, although it’d probably be a separate email.
        I’d also like to include a link to a FAQ or something explaining what it means for them, but I didn’t get that far.

        • Ipstenu (Mika Epstein) 6:54 pm on March 15, 2016 Permalink | Log in to Reply

          Having had to walk a few people through committing via the CLI in order to see the errors, yeah, they do :/ Or people just click ‘whatever’ and ignore… Both are issues. A separate email would be good. We can get to the FAQ. 🙂

    • Barry 4:51 pm on April 6, 2016 Permalink | Log in to Reply

      Sure 🙂 Whatever you think should be done sounds fine.

  • Andrew Nacin 10:19 pm on January 22, 2015 Permalink | | Unresolved

      Tags:   

      I have an nginx fix for a fun issue that’s breaking Jetpack integration.

      https://make.wordpress.org/support/xmlrpc.php isn’t being rewritten to /xmlrpc.php because /support/xmlrpc.php exists (it’s a bbPress file). /support/ is a physical directory that is bypassed for all subdomains, which means we end up rewriting it to index.php and thus a 404 results.

      The simple fix appears to be this:

      
      	# make.wordpress.org/support/xmlrpc.php needs to hit /xmlrpc.php.
      	# Without this, it targets /support/xmlrpc.php (a bbPress file)
      	# which is then denied and we end up with a 404.
      	location ~ /xmlrpc\.php(?:/|$) {
      		include conf.d/php-config;
      		rewrite ^ /xmlrpc.php break;
      	}
      

      This should go into conf.d/wporg-make.wordpress.org around line 60. I’m happy to commit this but I wanted review first.

       
      • seanosh 1:58 am on February 5, 2015 Permalink | Log in to Reply

        I’m OK with this (barring any other objections). Let me know if you need help rolling it out.

      • Andrew Nacin 5:53 am on February 5, 2015 Permalink | Log in to Reply

        I’m not positive the include conf.d/php-config.php + rewrite is correct, whether anything is missing, etc. It works and I can’t find side effects, but this is a bit out of my area of expertise.

      • Barry 7:39 pm on February 11, 2015 Permalink | Log in to Reply

        Maybe @pyhhak can take a look at this.

      • pyhhak 9:59 pm on February 11, 2015 Permalink | Log in to Reply

        You don’t need the php-config, just need to use normal rewrite (without break). Also your regex location would rewrite /whatever/xmlrpc.php to /xmlrpc.php, which is useless and more of a pain to maintain in future.

        If you only need /support/xmlrpc.php my suggestion is this:

        location = /support/xmlrpc.php {
        	rewrite ^ /xmlrpc.php;
        }
        

        I sort of tested it, and it seemed to work. Can you run your tests and commit it?

    • Andrew Nacin 6:15 pm on June 19, 2014 Permalink | | Unresolved

        Tags:   

        What can we do to improve the speed and reliability of Trac? I am seeing two issues in particular: it is terribly slow to complete a request, and web service gets restarted often due to the box maxing out memory.

        Possible ideas:

        • We could move from prefork back to threaded mpm to improve memory usage, but then mysql connections become blocking. What’s a possible solution for this?
        • Move Trac from Apache to nginx or using nginx as a frontend proxy, which would include a short-lived cache for reports and for users who aren’t logged in. Or, could we configure the existing load balancers in front of it?

        I’m most interested in nginx as a frontend proxy through the existing load balancers, as it seems like it’d be the easiest to set up and give us a decent benefit.

         
        • Barry 3:41 am on July 24, 2014 Permalink | Log in to Reply

          I don’t think it makes sense to utilize nginx on the LBs to do this but just install nginx on the SVN/Trac hosts and utilize uwsgi and caching.

      • Andrew Nacin 9:16 pm on June 3, 2013 Permalink | | Unresolved
           

          Priority: Low

          We can safely remove bbpress/public_html from web nodes, deploy scripts, etc. Everything is now in buddypress/public_html. Nothing uses it and nothing is in it except for download archive mount, which can go away. (The old releases still sit in SVN if we ever need them.)

           
          • Andrew Nacin 9:38 pm on June 3, 2013 Permalink | Log in to Reply

            I started this with r4723-deploy and r4724-deploy. Actually removing it from existing sandboxes and production would need a global command.

            It looks like the wporg-nfs-server role will need updates (and contains a lot of old release scripts we no longer need, as bbPress goes through the plugins directory for everything). That should be it, I gather.

          • Barry 6:28 am on December 11, 2014 Permalink | Log in to Reply

            NFS mounts removed.

        c
        compose new post
        j
        next post/next comment
        k
        previous post/previous comment
        r
        reply
        e
        edit
        o
        show/hide comments
        t
        go to top
        l
        go to login
        h
        show/hide help
        shift + esc
        cancel
        Skip to toolbar