A random bug and a memory error in WPMu 2.7.1

Update: The following error was caused by wp-cache.php. I disabled the file and WP-Super-Cache for the moment, and we’ll see if an upgrade of WP-Super-Cache doesn’t solve this error.

Every user that is not an admin on UMW Blogs seemed to be getting the following error in the header of the administrative backend:

Warning: Invalid argument supplied for foreach() in /home/umwblogs/public_html/wp-admin/includes/template.php on line 3169

It was highly annoying for me because I didn’t know how to fix it. But thanks to my main man Zach Davis, it is now fixed hidden by adding the following line of code after line 3169 in the wp-admin/includes/template.php, still working on a fix:

if(!is_array($actions)) $actions = array();

The other error I ran into today was related to a PHP allowed memory size within the adminstrative backend of the http://tags.umwblogs.org site (which is the place where every post in UMW Blogs is being republished using Donncha’s Sitewide Tags Pages plugin). Specifically, whenever I hit quickedit on a post in the backend, I would get this error where the categories and other metadata would show up, and when I clicked edit, the post text data would not show up at all.

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 524286 bytes) in /home/umwblogs/public_html/wp-admin/includes/template.php on line 419

The blog is huge, with thousands and thousands of posts, and I have a sneaking suspicion it is bursting at the seams. We have to find another way to archive and store this stuff once it reaches over 20 or 30,000 posts 🙂 In the mean time we upped the memory quota, but this is a shot-term fix— I think a long term solution might be something we may have to think through. Anyone have any ideas?

This entry was posted in wordpress multi-user, wpmu and tagged , , . Bookmark the permalink.

12 Responses to A random bug and a memory error in WPMu 2.7.1

  1. Yay! Jim used the word, “metadata”!

  2. Luke says:

    I’m shocked… SHOCKED… that Zach Davis came up with a fix for this that involved hacking the core. Is he going soft, or was he just trying to get you off his back? Tell me he at least gave you a good tongue-lashing.

  3. Zach Davis says:

    Ok. Time to set the record straight.

    First off, I just fixed the problem – all I knew about the error I was fixed was a) the line number of the error and b) the fact that it was in a PHP file that was over 3,500 lines long. Nobody told me I was in “core” territory!

    Plus, 3,500 lines of PHP kind of makes a discussion about core vs extension besides the point, doesn’t it? Especially when there is HTML mixed in throughout the code. Please, all you WP fanboys – take a few minutes and consider some basic concepts like this – http://en.wikipedia.org/wiki/Presentation_logic – and this: http://en.wikipedia.org/wiki/Business_logic. When we’re talking about 3,500 lines of procedural code, with not a class declaration in sight, there’s not even the possibility of applying a sensible fix.

    Second, you’re damn right I gave him a tongue lashing. You think I’d miss an opportunity to bitch about the quality of WP extension code? Not on your life.

    Zach

  4. Reverend says:

    Zach,

    Are you gonna bark all day little doggy, or are you gonna bite? 🙂 Thanks for the fix, it was a highly annoying error, and I really do love it when you rip on WordPress code, because it kind of tempers some of my enthusiasm, at least until you get rid of the error message.

    While working with a prof today in WordPress I realized that error message is linked to the quick create button for writing a new post or page at the top of the admin template. It is a necessary feature, so I actually do have to figure out a fix. I hate to go to you with this stuff—well only a little bit, it keeps us in touch—but I could find no one else with that same error in Google, which makes me think it is caused by one of my 5 million plugins. I still have to get that working, but for now I like the backend error free. So when you have some time can you sort through the 3500 lines of PHP code peppered with HTML and get a fix so I don’t have to hack the core?

    Thanks bud, love and kisses,
    Your father!

  5. Luke says:

    Awesome. This will get me at least through July before I need to seek out another good public Davising.

    I totally buy and appreciate your critique of the WP code, which really is teaching me much. At the same time, Jim’s error was actually caused by *something* on his install, rather than being caused by the absence of the line you added (to the business logic side of things). Wouldn’t the “sensible fix” be figuring out what was creating such a unique error message? In all likelihood, as Jim says, it’s a plugin (presentation logic). If not, then perhaps its something more concerning. Of course, if the entire structure of the application is indeed senseless, then a sensible fix isn’t impossible!

    Either way, you did for Jim what we always to for faculty to get them off our backs and through the semester… Zach is so edupunk!!!!! (This is fun, but would be funner over beer… and, if Zach responds, I totally expect it will get me through the end of the year).

  6. Zach Davis says:

    Maybe – I mean, I think it’s fair to expect that good code would check to see if a variable was typecast correctly (as an array, in this case) before passing it to a loop. But it’s a common mistake – easy to make, easy to fix. My bitch about the code wasn’t about the error. Rather, my bitch is about how much WordPress fails when it comes to looking out for the developer. When I use wordpress as a user, I think it’s fantastic – a lot of its success is certainly because it cares about usability (which, of course, comes out of caring about the user). But, when I come at it from a developer’s perspective, I always kind of bummed out to see how little wordpress exhibits a lot of the current best practices in PHP development.

    As for plugins being presentation logic – that too seems wrong to me. I mean, a plug-in shouldn’t be any different from any web application, insofar as it needs to render HTML (on the backend and on the frontend), which is the product of the presentation logic — while also containing code that meets a business goal (database transactions, logic, etc), which is the business logic (I’m using business loosely here – not business in the sense of businessmen, but business in the sense of getting down to business, getting something done, “it’s business time”). But every time I look at code for WP – and I might just not be looking in the right places, as WP is definitely not my daily bread and butter – I see a total lack of separation between the two. Heck, in WP, the API is basically a set of available function calls, isn’t it? What about private and public interfaces on objects? What about real object oriented code and proper encapsulation? These things make a difference, after all – they tend to make for code that’s better thought out, less procedural, and easier to maintain and extend.

    When you’re edupunk, after all, and you don’t have bloated IT budgets backing you up, don’t you have even _more_ cause to look for these qualities in software in order to minimize the labor required to keep these sites running smoothly over time? I can tell you from recent experience that it takes me three times as long to make changes to a WP site than it does to make changes to a similar application that’s running on relatively object-oriented code that follows a clear design pattern (MVC, anyone?)

    It’s Miller time, boys – I got a lawn to mow and a new Mos Def album to listen to while I do it, so we’ll have to share the beer in spirit this time.

    Zach

  7. Luke says:

    First of all, it’s just not a fair fight if you’re going to start talking in Latin.

    Second, it seems to me that maybe one of the theories behind WP… purposeful or not… is to break down some of that separation between business logic and presentation logic. That seems to be a necessary implication of empowering the user to have more control over their space (via plugins & themes, both of which are now searchable and installable via the admin panel, though only themes and plugin that have been submitted to and approved by wordpress.org).

    Still, no user on our systems has access to the file that you fixed; only the admin with FTP access does, so I’m not sure if I’m fully following the “private/public interface on an object” argument. Plugins seem to bridge that particular gap, and it’s totally appropriate to point out that such a process is a sloppy one… any WP admin has had a plugin crash an install. At the same time, as you noted, WP cares about its users and empowers them… and, it also empowers people like Jim and me, who are complete hacks (sorry Jim, but truths must be told!), to quickly build and support expansive, relatively stable systems. If the private objects were really and truly private, you wouldn’t have been able to solve that problem for Jim, and I wouldn’t be able to try to make the Kitchen Sink in the visual editor default visible for our users (my next attempted hack). Is it best practice to do things this way? Only, I suppose, if you’re a Deweyian. I’d prefer a “public” way to do that, but it doesn’t (yet) exist.

    So, there’s opportunity there, both for us to customize with limited skillz, and for us to fuck things up (because we have limited skillz). Our users also have those same opportunities, albeit on a smaller scale. I don’t know of other applications that combine such ease of use with that level of empowerment. Can you have such benefits without the costs? Drupal, Joomla, Plone… they all have reputations for better architecture (I believe they’re all MVC) than WP, and I understand why. But they also require more esoteric knowledge both to administer and to bring users to. You gain, but you lose, and in communities like ours, ease of use is priority 1,2, and 3. May not always be that way, and probably shouldn’t be, but it’s where we are right now.

    As for the edupunk in our environments note, really, our install has been remarkably stable… our only issues have been server/load balancing issues, which aren’t caused by the software (though WP could certainly be more efficient in that area). A skilled sysadmin could probably have us humming along with fewer than 8 hrs a year. Further, I can’t even get my head around the concept of “over time” these days, given the rate at which standards and opportunities change, and given the fact that I’m on a year-to-year appointment. I agree that we have to start thinking that way, too, and it may problematize WPMu a bit.

    Thanks for this… it’s really useful for clarifying my thinking about aspects of my work I’m still relatively clueless about.

  8. Matt says:

    Fascinating discussion guys — one that obviously builds on some of the conversations we had in NY a few months ago.

    What interests me is the ways in which the messiness of the WordPress API opens up interstitial spaces for users to experiment and play with their sites. When I look at sites produced by cleaner coding systems such as Drupal or (dare I say it?) Typo3, I see a certain rigidness that seems to be a direct result of the structure of the code.

    As Luke and Jim point out, the great thing about WordPress *is* its messiness, its openness, its empowerment of its user community. Zach’s point that the code isn’t ultimately scalable is a little problematic in the face of wordpress.com, which supports millions of users through a wpmu install.

  9. Luke says:

    Interesting solve, Jim. I think wp-cache.php when combined with Tan-Tan Noodles Flickr Album caused a recursive loop on our site when the CUNY server indexed us… totally spiked our load for a day, even though the path was beyond a rejected URI. Something to watch out for…

  10. Zach Davis says:

    (NOTE: Linking to code examples because comments won’t accept code)

    I’m trying to make some technical points here, and you guys keep spinning them off into conceptual points. There’s nothing good or desirable about a messy API. That’s like saying that a poorly built house with holes in the wall is great because it’s easier to see the wires running behind the drywall. I suspect that your issues with Drupal or TYPO3 aren’t about the architecture of the underlying code – your issues are about how the paradigms that those applications follow. Heck, TYPO3 doesn’t have a MVC based architecture (well, it will in the upcoming release, but previous ones don’t). Drupal is awfully close to WordPress, insofar as it relies on a series of hooks and callbacks for templating.

    By definition, a well thought out API would make it EASIER for people like you to do things in wordpress, not harder. I keep getting the sense here that there’s this unspoken assumption that the needs of the developer are somehow at odds with the needs of the amateur, but that just isn’t true in most cases. The WordPress API, as I understand it, is basically a series of hooks. What that means is that as the code is executed, there are places where your custom code can hook into the chain of execution and make something happen. That’s just not a very sophisticated model because it’s limited by the timeline of the code execution. If that execution timeline doesn’t work for you, you’re out of luck – or maybe a developer will add a new hook. It’s a limited model – There will never be enough hooks to meet every developer’s needs. All I’m arguing for here is a better architecture, in which we can deal with the various models that make up the blog domain (posts, comments, collections of posts, tags, users, etc) in a more object oriented fashion.

    If you guys think you’re getting a good deal with code like this, taken at random from a WP template, you’re wrong:

    Code Example 1

    I understand that this works, but it’s not the best way to do things. Better, would be to have access to the elements as objects that can be extended. It would also be better to have a clean, simple templating syntax:

    See Code Example 2

    If post is an object, rather than a series of predefined PHP functions, then it can probably be extended, which means I can, in theory, write my own custom code that safely and cleanly extends the post:

    See Code Example 3

    In creating public methods on my new object, I am, in effect, creating an API on the fly that a template developer could take advantage of:

    See Code Example 4

    There are all examples, of course, but the point is that the things I’m arguing for – clean code, object-oriented code, public and private interfaces, separation of view logic and business logic, real APIs (not just a series of hooks and events) – are not at odds with what you want, but actually perfectly in keeping with those things. When code is procedural, like the wordpress code, you’re by and large locked into that order of execution. When code is relational and object oriented, you can generally extend those objects, create child objects, and make that code do things that it wasn’t originally meant to do. Procedural code is almost always slow to respond to changing requirements, whereas object-oriented code tends to be much more agile and flexible, when done correctly.

    Why does quality and craft, I wonder, always seem to end up being at odds with this thing you call “edupunk”? If openness is a key value, then the code qualities I talk about above – the very architectural qualities that guarantee openness, flexibility, and re usability – should be a central part of the enterprise.

  11. zach whalen says:

    This is an interesting discussion.

    I don’t have much to contribute to either side, but I want to throw in a shout out to Drupal because I think it *is* in fact evolving to move more toward the object-oriented paradigm you’re talking about, Zach.

    Many popular modules are actually both a module and an API. Right now, for example, I’m working on hacking the latest version of the gradebook, so I’m writing my own submodule using the tools provided by the Gradebook API modules. This includes functions and a db schema for common tasks like setting grade values. So it’s nice. I don’t know, however, if that counts as a “real” API or if it’s just an abstraction of more “series of hooks and events”. To use it, I write code to execute within a series of Drupal hook functions that fire when called, so it’s definitely still a procedural model at its core.

    In terms of content and templating, though, I think the CCK concept (which is moving into core with Drupal 7, I believe) is a great example of agility and flexibility. Back when I first started messing with drupal, I had to write my own module for each type of content I wanted to make. Now CCK handles all that. And then you can template that with the Contemplate model using code that starts to look more like your examples.

    To use Contemplate to modify the output of a node, for example, I can do things to a node->body object.

    To put this back into the realm of the expert vs. amateur, the point is that with CCK (and Views) you can now do some pretty complicated stuff with content that you otherwise had to write (sloppy) code for. Of course, there’s still a learning curve, and that’s a big problem for Drupal that I know they’re working hard on for Drupal 7.

    Anyway, I’m not a programmer, and what little I know of Drupal code far exceeds what I know of wordpress code. So all that is just to bring Drupal into this conversation to say that I’ve watched it evolve and its steps forward have been (I think) along the same lines you’re talking about. I know this flexibility is why I prefer it over WordPress as a platform, even if I can’t confidently say how well it approaches the kind of code quality Zach describes.

  12. Zach Davis says:

    That’s interesting, Zach. TYPO3 is moving in the same direction – they just put out an alpha release of FLOW3, which is a MVC framework that the TYPO3 5.0 team developed as the foundation for the TYPO3 5.0 release. I recently heard Robert and Karsten, the core developers, discuss the ideas that were driving their development, and I was totally blown away about how they were incorporating a lot of pretty cutting edge thinking. And I’m not just talking about the MVC pattern – they were thinking about domain driven design, aspect oriented programming, all sorts of stuff that I could barely keep up with. It felt like something exciting was happening on that project, listening to them speak, and it’s interesting to hear that Drupal is also pushing forward and thinking hard, as a project, about what the next direction should be. I think that by staying on top of new trends and emerging best practices in web development, these projects have a much better chance of becoming viable solutions at the institutional level. The multitude of web frameworks that have come out in the past few years – symphony, cake, rails, to name a few – have made development exciting, I think, for a lot of web people, and have pushed many of us to think in new ways about what good web development looks like. I hope wordpress dev have seen the way the winds are blowing – they probably have and I just don’t know it, god knows there are some smart people working on that project.

Leave a Reply

Your email address will not be published. Required fields are marked *