mindplay.dk

Just thought I'd bring up one thing that sort of slows me down in the admin-interface. I think it's fair to say that the sitemap in PW is the "heart of the beast" - and as such, I feel that this could be improved in the following way: I'd like to see the sitemap (and possibly the primary admin shortcuts) stay docked on the left side of the screen - and have the sitemap maintain state, e.g. avoid reloading it on every request, and avoid having the sitemap "forget" what was open and closed. For the most part, the admin interfaces leave plenty of horizontal screen real-estate - and if the sitemap was permanently docked on the left and would collapse to a thin vertical ribbon, you could still use 98% of the page width for the admin-interface. This would probably also reduce load-time on admin pages somewhat, as the individual screens would no longer need to render the primary navigation and traverse the sitemap. Perhaps this is a theme-job. If so, I'd like to hear from someone who has written a theme, do you think this is feasible without making changes to the core? Can a theme diverge from the usual workflow in this way? Thanks!

I was happy to see this has already been mentioned and is under way! Icons for templates would definitely make it faster for a content manager to browse the sitemap. However, I'll just briefly mention one small reservation/concern I have about this... I really like what this theme does - as far as using icons to indicate the state of an item, rather than the type of an item. For one, the state of an item is sort of unclear at the moment - I know the color-coding of items is supposed to indicate this, but most people I've showed PW to so far don't see to pick that up without some explanation. Another factor, is the fact that you're most likely going to have a high number of templates, and a low number of states - I personally find that icons are most useful when there's a low number of different icons. When you have a high number of different graphical symbols, reading pictograms starts to take more effort, and it gets to a point where there are so many types of icons, you simply start to ignore them. Just something to consider: perhaps it would be wiser to use an icon to indicate the state of the items. And rather than using icons to indicate the type of item, perhaps it would make more sense to use color-coded badges to actually display the template-name - something along the lines of the labels you see on e-mail items in gmail. The color-coding and varying width of the badges helps you recognize same-type items intuitively - as opposed to a large number of same-size (and probably same color-scheme) icons, which quickly turns into "icon soup". Just something to consider.

Anyhow, to the subject at hand - if you don't want to merge my changes, can you post here and let me know when similar changes have been implemented on your codebase? I'd like to pursue the namespace-conversion, but as mentioned I can't continue from my own branch since your changes would not be identical to mine...

A similar color scheme is available in PhpStorm. I haven't used Sublime, because I finally found my IDE - but I have heard many developers say very nice things about it... For one, it's supposed to be extremely fast - where most other IDEs (including Storm) feel kind of sluggish in terms of display updates...

Out of the box, there will be plenty of auto-complete, auto-indent, code-collapsing, auto-everything - you will figure out how to turn most of that stuff off or adjust it to minimize the noise. What's really helpful is things like function-parameter hints, and the ability to rename a function or variable and have the changes propagate automatically. Support for doc-blocks is something I really enjoy as well - it encourages you to document properly, declaring return-types, etc. The "code style" configuration is really detailed and helps correct inconsistencies in code-formatting. In a lot of ways, it just whips you into shape - or if you're already a total stickler, it helps you catch up quickly when you make a simple typo or forget to document a change etc...

Ryan, I also spent lots of time with many different IDEs over the years - I too started out in Borland/Turbo/Delphi, and like you, Photoshop is one of the only non-minimalist apps I've been lugging around for over a decade. I think we have a lot in common that way. I have tried every PHP IDE there is, big and small, and PhpStorm finally swayed me, so they must be doing something right! If you're like me, it'll take your a week or two to discover the settings to tweak to turn "too much" into "just enough" - like all IDEs, Storm does a lot of hand-holding out of the box. But I'm really happy with it now and can't really imagine programming without it at this point. Anyway, I wasn't trying to turn this into an IDE discussion, but I really think you might like this - it sounds like we have some of the same mind-set and background Don't count on FIG recommending this, as the only purpose that would serve (for most people) is performance, and only to a very minimal extend - and not even that, unless you're hosting PHP without a bytecode-cache...

Hey Ryan, Maybe it's time to try out a real IDE? I highly recommend you give PhpStorm a shot - I became addicted pretty fast about a month ago, and like you, I was a die-hard plain text-editor addict for 20 years, so I really say it's worth a shot Yes, I think the push for PSR-0 compliance is worthwhile in the short-term. I wouldn't worry about the two dozen or so new files from a performance stand-point. Sounds like your issue arise from limitations of your editing environment more than anything else - one file per type is preferred by most people I think, since it does simplify finding a specific class or interface, when you don't have types that are "hidden" in another type's file. Porting the modules to PSR compliance looks like a bit of a dirty operation, I agree - it will change the plugin standard and render existing third-party modules unusable without some (minor) changes. Perhaps it would be better to make that change in a major release. It would be nice if you would do your new development in the open - on a branch. So we can keep up with what's coming. I have a feeling I'm going to be quite involved in PW in the future, as there is great support building up for PW where I work - we haven't used it on a project yet, but several people in the office have been testing it and seem really excited about the results so far

@Ryan there is one small problem with your approach of re-implementing all the changes... I can't actually continue with the more complex changes - because the next set of changes will be a branch based on the first set of changes. Are you willing to consider pulling? Otherwise, basically I can't really continue until you review and commit the same changes to your master-branch, as your changes would not be (byte for byte) identical to mine, and thus you would not be able to merge my next branch... I would need to wait for you to implement these changes and then branch from your master-branch again before implementing the next set of changes... PS: if you grab the latest version of "migration.php" from above, you can see this brings down the number of warnings considerably - there is also a list of notices output by the latest version of this script, which can help identify include/require statements that need to be reviewed...

Alright, the first pass for "wire/core" was pretty easy - have a look. This doesn't seem to break anything - fortunately PW doesn't have a million admin-screens, so I clicked through all of them, and everything appears to be working normally. If you'd like, I can send a pull-request? I wonder if I should branch again before starting some of the more "dangerous" work...

Yes, there is a small performance-impact by using more files - that's why I asked, some people are hysterical about 0.1 msec of overhead on a page-load. On a server that uses a bytecode-cache, the impact of a few more files has no significant impact on performance. On the contrary, if we were to package the core-classes in a phar-archive, individual classes and interfaces would actually load slightly faster than they do now. Reviewing and tweaking changes made to your codebase by third parties doesn't sound like a bad idea at all - actually, I find it reassuring that you're that careful. I am not a Github wizard myself, but I was recently corrected when I forked and posted a pull-request without branching - supposedly branching makes it easier to merge, I don't completely understand why, but you don't seem to care anyhow, so... I can see how the impact on modules is potentially harder to predict, so I'll stay away from that - let's take one thing at a time. I'll take a look at fleshing out the core files and possibly packaging them as an archive, tweaking the auto-loader etc... PS: Just for the heck of it, could you point me to the class/method that enumerates modules? I'd like to take a quick look and assess the potential complications.

@Ryan: you liking my last post, should I take that as "yes, I agree"? If so, I might fork PW and take a stab at the clean-up round myself. I don't want to spend a lot of time on it though, if you're already doing it, or if you have reservations about breaking types into separate files for some reason... (what's considered good practice? fork, modify and pull-request - or fork, branch, modify and pull-request?)

@Ryan: running the script now should give you a pretty clear overview of things that need to be corrected to comply with PSR-0: correcting filenames and breaking classes/interfaces into separate files. I think these can be implemented on the current branch, without breaking backwards compatibility? (with some simplification of the autoloader.)