Leaderboard

Fancy Admin Mode Just had a little funwith fancybox iframes, and created a little module that opens all admin links (topnav links, edit, view, new, copy actions) except "Pages" screen and "Site", "Search" in a FancyBox, so you'll never leave the page tree. It even works with inherit editing child pages. Download: https://github.com/s.../FancyAdminMode Little screencast to se it in action:

Here's what I'd share: Connect with other creatives. Graphic designers, photographers, marketers, etc. If you feel like you are not at the top of the list of great web designers, that's normal. But imagine how the average print designer feels about their own web design skills. Talk to those people. Many of them already have many clients who could use websites that work. Instead of spending your time cold-contacting people you want to work for, cold-contact people you could work with. (see above) They will see the value you bring into their business. Hire a business consultant, if you can. I hired a retired tech executive. His advice has saved me from making really dumb decisions, and helped me make some really important, yet difficult decisions. I have a notebook full of this stuff. Stay in the game. Don't give up on it and call it a crappy career just because you haven't been able to develop the skills yet. Lawyers are told to take 7 years to get established. Web designers might not even need that much time! But it does take some time. Take care of yourself. You will run into stressful situations. Be sure to do the things that keep you healthy. Get exercise, eat healthy food, spend time with people you care about. Avoid: Late working nights, mind reading (guessing that your clients hate you or think you're too expensive), and meetings with people you aren't interested in working with. Plan your next day every night if you can. Ask yourself what is going to happen tomorrow that will push your 5, 10, 20 year goals ahead. This is a great way to relieve stress and help you sleep better too. Provide value to your clients. Solve their problem. If the solution is a different web designer who's cheaper, tell them that. If the solution is some cheap third-party blogging platform, tell them that. If the solution is exactly what you do, give them estimates for "small, medium, large" and let them decide how much money they want to spend. Don't drop off a solution at the door. Stay with them. Offer to stick around for the first 6 months their new website is live, and handle some of their blogging or other updates. Offer to meet with them and review their analytics. They will need your help. They don't want to fail. Write about what you are doing. Keep a blog somewhere too. Share your thoughts online. Be nice to other web designers. Anyway, about what we do: This is a great way to make a living. Keep at it. Edit: You don't have to work for an agency. You can do this on your own. I've never worked for an agency except as a student, and I thought the agency model had some pretty obvious weaknesses in terms of output. I've had a couple agencies hire me to be their web guy's web guy, which sort of points at the problem. But you can also work alongside agencies (i.e. client pays you both separately), which has brought me great results.

All cheaters!

Joost de Valk recommends that on Wordpress you change the permalink to just the post name, so my answer would be to save yourself some work and don't bother.

Hello Everyone, Thanks Soma! My reason for asking is because, except for a handful of actions, I have been able to replicate everything I was doing with CodeIgniter/Laravel here in ProcessWire. Actually, on the Laravel forums there are two related discussions about this. If you haven't seen them already, go here: http://forums.larave...id=21881#p21881 http://forums.larave...?pid=4627#p4627 There is also this: https://twitter.com/...018610362232832 I find this significant for a couple of reasons. First, because there have always been three branches of Web development for me: 1. Pure and Naked PHP 2. Fully-Baked CMS 3. PHP Framework I'm being a bit colorful, but I think you all know what I mean by "pure and naked" and "fully-baked." Of course, there are CMSs built with frameworks, but I had never found one that maintained the total freedom of the framework while also providing the crucial "engine" of a CMS without making too many assumptions. I know a few that come close. ProcessWire is the only one I have found (and I have tested a very long list of CMSs and framework-based CMSs). The "fully-baked" CMSs are not worth comparing really. If people in the Laravel community are recognizing that ProcessWire does the framework-based stuff really well, and also gives you those CMS functions every project needs, it's a big story. Thanks, Matthew

It's not about quality or likes of the posts, it just about the quantity!

you foto. in forum faq listas long.time my.turn

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Thanks Marc, there's some really useful advice. I especially like the bit about looking after yourself. I find it exceptionally hard to switch off the computer at night if I've not solved my latest problem! Good article too.

if($field != "InputfieldTextarea") return; I'm not completely getting it about derivates. But of course I wasn't thinking about all consequences and what would be best way to go. But Ryan think makes some valid points here. Extending InputfieldText or Textarea and just create a field for having counters versus a module only with options to chose which text field has the counter might work, but would need to also be able to make counter settings for each individual. Damn so many options it's hard to see through

ProcessWire core is a framework. And on top of that built a CMS I think it goes this far /wire/core - is the framework /wire/modules /wire/admin-templates - is the admin/cms built on top of the core /site/ - your site with possibilities to extend admin and cms functionality You could start now and build your own CMS basing on core.

I Would like to throw a huge, hefty spanner into the works here! (Just for fun) If you split PW into two piles, in one pile you have the Site directory. Here is, or will be, your CMS. PW gives you a starter, but once you get into it, you are going to build your own content management structure in there on top of the base. In the other pile is the WIRE directory. However, this is NOT a CMS, or perhaps even a CMF .... I have a suspicion that it is really a CME - a Content Management ENGINE! Joss PS: I have this great want to rename the SITE directory to PROCESS ... just to round off the gag.

Love it! It's a different way of always having easy access to the tree and not losing your place. The way I was thinking of last week was having the page tree in a sidebar area a bit like MODx but this works better with any size of website. Now slow down, you're making the rest of us look bad

http://ace.ajax.org/#nav=production We're on the fourth line

Okay, shot through the General Support (30 pages) I found a few that were moved topics, 5 others where the poster had answered their own question and one that I answered for fun. (See Diogo's post above) The ones where they had answered their own questions were from experienced users. I did not find ANY in General from new users that were unanswered. Oh, there was one. It was "post your questions here" from some bloke called Ryan back in December 2010. I wonder what happened to him? Probably went off and used Joomla.... That is a pretty good record! One very impressed Joss

Hey Ryan, I saw your recent commits to the ImageSizer and was wondering if you could also add the ability to provide a custom center value (x, y) to the ImageSizer? Like: setCropping(array('30%', '40%')) or setCropping(array('200px', '300px')) Sometimes you know exactly what the most important part of a uploaded image is. And this could also come in handy when developing a InputFieldImage module where the user can click on a image in the page editor to define his own cropping center (or focus point). Most images have a certain point in a image that is most important (like a human face) and should always be visible in crops. Greetings, Niek

I tried to integrate parts of another site with ProcessWire today, and quickly gave up, as my existing (older) site has a bunch of classes in the global namespace that collide with some very generic class-names in ProcessWire: Database, Config, Session, Page and so forth. Would you consider introducing support for namespaces? Perhaps in ProcessWire 3.0, as clearly this would break backwards compatibility with the current API. Simply placing PW classes in a vendor-namespace (e.g. "wire") would probably be sufficient to avoid 99% of collisions. I think it would be great if PW-modules followed the "{vendor}\{package}" namespace convention for modules, as this eliminates practically all namespace collisions. Both conventions are compliant with the PSR-1 recommendation - though vendor-name is the minimum required, but I think that's fine for the framework itself. A "smart" IDE like PHP Storm could probably refactor most of the codebase to use namespace more or less automatically. If you're interested, I also have a script somewhere that rewrites entire codebases to namespaces, picks up folder-names and maps those to namespaces as configured. (it's not complete, but would probably get you roughly 971/4% of the way...)

I was thinking of a way of creating custom admin pages without having to create a process module or having to use the $wire object. I came up with a process that is actually very simple (although I think it would be better to create a module for having this functionality). Here is how: (This will work with the default admin theme, but should also work with other themes) Go to your /site/templates-admin/default.php (if you don't have it, copy the /wire/templates-admin/ directory to /site/) and change this line <?php echo $content?> to this <?php if($page->template===$templates->admin){echo $content;}else{include($config->paths->templates.$page->template->name.".inc");}?> Then, go to the /site/templates/ folder and create a file named "custom.php" with this content <?php include($config->paths->adminTemplates."default.php"); Our setup is ready Now, to create a custom page in the admin: First, create the new page as child of /Admin/ and point to custom.php as the template file. To do this, when creating the template for the page, go to "ADVANCED" and write "custom" as the "Alternate Template Filename". Then, instead of creating a TEMPLATE.php file, as you normaly would, create a TEMPLATE.inc file. You can use all the API variables as you would in a normal template. Disclaimer: This is a proof of concept, and has still lot's of place for improvement. edit: changed from this if($page->process) to this if($page->template === $templates->admin)

You are correct, the = Equals works. It's the only selector that works. I realized that you can't mix native and custom fields together. Not sure why, but ok. I went into the "Page Search" Module and changed the settings.

Search in field(s): name Type of search: Equals (a=b) These settings works for me.

Yes those are just properties I've set to change the two fields and templates more quickly. It could be done differently. Also there could be some configuration with 2 dimenstional array to map many fields and templates and the mapping part could also be a little more abstract, but it's nothing too serious and just a quick straight forward proof of concept that for now works. I'm not sure how mapping could be done better scaleable and reusable, but sure this would take some good implementation rethinking. A dedicated field approach extending page field, that may even adds another table to do it. All just hot air for now. Edit: You use set(key,value) So it would be $this->set("tpl_team","team"); // template $this->set("users_select","team_mitglied"); // its page field $this->set("tpl_user","mitglied");//template $this->set("teams_select","mitglied_team");// its page field and this may also work if you peferer $this->tpl_team = "team"; // template $this->users_select = "team_mitglied"; // its page field $this->tpl_user = "mitglied"; //template $this->teams_select = "mitglied_team";// its page field

Many, many years ago there used to be a UK sitcom about two old tailors called "Never mind the quality, feel the width!" A perfect adage, as far as I am concerned.

Umm, may I ask why I'm "just" second? And I mean by judging solely based on likes-to-posts ratio as I'm not capable of doing anything more than that.

HI and Welcome FuturShoc Adding an image to a TinyMCE field requires an additional image Field. On your template, add the Body Field (which is already set up with TinyMCE) and the image field which already exists. Go to page and add a new page, selecting your template. On the ..... Oh, blast - dave got there first!!! Well, just to finish, when you click on the image button on TinyMCE it will open a custom insert image popup which will list any image you have uploaded with the image field. Choose one of them and you will be able to resize it and choose its alignment. As DaveP says, you just then need to make sure you have the right CSS. If you are just starting out, try the Panet project but also, you may want to have a go at this much more detailed tutorial: http://wiki.processw...ebsite_Tutorial Good luck, and keep asking questions!

This was recently contributed by another user via a pull request, so it's currently undocumented (aside from here). I'll add this when updating the documentation for stuff in 2.3. Though these operators were added in the 2.2 stable.

OT @Ryan: Wanted to ask you lately anyway: Which are the two fonts of the logo?

The problem with derivates will occur, if someone adds another module where the counter doesn't fit in to InputfieldTextarea (like with TinyMCE). This won't break anything directly, because the counter only comes to action if you enter limits in the field configuration, but still this is something making it possible to do something wrong (and maybe don't get why). The simplicity of if($field != "InputfieldTextarea") return; is a good idea to prevent this. On the other hand this will also prevent adding the counter to derivates of InputfieldTextarea where it actually would make sense. The same is true for making it as a distinct field, because it wouldn't allow to add functionality with modules working with InputfieldTextarea hooks only, even if it makes sense. Ryans proposed solution with a config setting to select on which variants of Inputsfields this should act would be the most flexible solution, but on the other hand, Soma, you're right about options everythere, this is really overcomplicating things for the clueless user. I think all different methods mentioned here have their pros and cons, I'm not really sure, which one would be the best way to go. Maybe there are even more options?

Hey Alessio thanks for your reply! It's interesting hearing your point of view. I always guessed that web is sort of the opposite to normal careers. You have to start out on your own, prove yourself and then maybe you can work for an agency. In other sectors, when you've learned the ropes you can go out on your own! I'd love to work for an agency making sites while continuing to improve but I've no idea at what level the jobs are available at...

Hi onjegolders, Very interesting topic! I work for a web agency since 2009 and i also made some tiny sites alone, but only now i'm quite secure that i can build all types of site. Some years before i was very afraid/insecure when the clients asked me something different from a basic site. What i can suggest is to begin from search a web agency where you can learn while you make money . When i started where i'm now, i learned in a year more than 2 times of what i learned at University! I'm very lucky because the web agency where i'm employed is very open-mind and full of new project, so i learn every day. In my own opinion, if you start to build, alone, without clients, and you have only small projects ( 500€/1000€ more or less 400/800 pounds )... Well it's hardly. Obviously without the bureaucratic of manage a company although small ( in Italy is a sucide! ). I hope i helped you in some ways!

Done most of the bits on the Tutorial, apart from the code issues - added a reply to your comments. Edit: And done the other ones too!

Ryan, thanks a lot for looking into this, your feedback is very much appreciated! You're raising a really valid point there, I didn't really think about problems with other derivates, but you're completely right. I think this should be approached before submitting to the modules directory because depending on the solution, it might block the easy update path for some users later. I'm not so shure which of your proposed solutions, that all sound reasonable, is the way to go here. Thus my question about the module as an input field itself: would there be any problems for a user to change from a normal InputfieldTextarea to a InputfieldTextareaCounter and back? If this is trivial (as it looks to me), I think this might be the cleanest solution to do it. Otherwise I like the checkbox solution second best, but it requires more configuration knowledge (I already see the "Why is my InputfieldXY behaving strangely?" thread in front of my mental eye).

Tested here and works great! Thanks for making this Boundaryfunctions and Soma! I look forward to seeing this in the modules directory. This is a very useful module for sure. Minor point, but longer term, I wonder about the hooking method and whether that might present problems for future InputfieldTextarea derivatives. This one specifically excludes TinyMCE, but feasibly there are future others it might need to as well. It makes me wonder if this module might better exist as an Inputfield itself (InputfieldTextareaCounter) or perhaps as a module config setting where you check boxes for which Inputfields it should apply to. Or perhaps as a core addition to existing InputfieldTextarea. These are just ideas for the future, but seems like what you've got here now is working great and I look forward to using it!

Ok the while is over. I just committed an update to 1.1.5 to support alternative markup for specified templates. https://github.com/s...default-options Added 3 new options: "xtemplate" => "folder|placeholder", // specify one or more templates "xitem_tpl" => "<span>{title}</span>", // default markup for page with this template "xitem_current_tpl" => "<span>{title}</span>" echo $nav->render(array( 'max_levels'=>2, 'selector'=>"limit=10", 'xtemplates' => 'placeholder|folder' ));

Hey Ryan, It's always very reassuring to see your name and face in a discussion! I'm very glad to know that these validation elements are in the development branch. I'm going to start testing/using that one some more! I guess this is one more reason to be excited about the next version. Thanks, Matthew

I think a better search module in the admin (no offence ryan, it does work as it is of course!) or at least an alternative could be implemented whereby you can select fields/templates/pages and do some really advanced things without getting overly techy with selectors. As a real-world business example, creating rules in certain versions of Outlook takes you through steps - not that this needs steps - of selecting your first criteria, then a second and so on. It would be neat to be able to chain criteria in a drop-down interface where you can have as many criteria as you like with one per row. For example with drop-downs and some AJAX (for subsequent drop-downs at that stage) you could achieve: 1) Template equals "blog-page" 2) and body contains "pasta" What I mean by this is that for users who aren't the web developer there could be an easier way to present searches in a way that reads exactly how it appears on screen. The two separate lines are for two criteria, but equally you could add 6 for a big site to drill down into some complex stuff. Just thinking that something human-readable (devs are super-human of course) will be better for the less techy content editor whilst devs should be aware of the selectors by the time they've built the site

Update: new versions (v2.5.0 and v3.5.0) now available. Yes, two versions. Both are feature compatible (at least they are at the moment) but differ in that v2.5.0 is not PSR-0 compatible as it doesn't use PHP5.3's namespace facilities. v2.5.0 only needs PHP5+ and is therefore suitable for projects targeting older versions of PHP. v3.5.0 is PSR-0/1/2 compliant and needs PHP5.3+ for namespace support. @Ryan, I'll be in touch soon about taking over maintenance of the Textile text-formatting modules for PW.

You should use markupCache module instead and cache only parts of your output. So your code might be something like that: <?php $cache = $modules->get("MarkupCache"); switch($session->typeOfVisitor) { case "lucky": if(!$data = $cache->get("lucky")) { $data = "You are lucky"; // Here you would actually get the real output... $data->save($data); } echo $data; break; case "unlucky": if(!$data = $cache->get("unlucky")) { $data = "You are unlucky"; // Here you would actually get the real output... $data->save($data); } echo $data; break; }

turn url segments on your category pages, and then something like this code (browser written, untested): <?php $post_name = $input->urlSegment(1); $post = $pages->get("/posts/{$post_name}"); if ($post->id) { // render post } else { throw new Wire404Exception(); }

Multiple things: [#] Not sure whether this is the best thing ever or worst thing ever [#] Could those stacked fancy boxes open kindof like basecamp does it? (that would be rad)- [#] This actually needs it's own theme, or should be made as a theme, I think. God job.

Another example.. build from ProcessHello and really fresh: https://gist.github.com/4289451

I have implemented TinyMCE, AlohaJS (when it still had ExtJS dependencies) and now CKEditor 4.0 in various projects and I have to say that I really loved how the CKEditor 4.0 works. It was very fast to implement, easy to customize, works fast and it supports both inline/textarea... It has brilliant documentation (http://docs.ckeditor.com/#!/guide) and as a cherry it looks very pretty. After I have implemented it in this project (I use it for frontend editing in this case) I will definitely look for implementing CKEditor Inputfield. I think the table editor alone is so much better than what TinyMCE that it is worth it. But also looking for some nice scenarios to implement CKEditor on frontend - maybe with AdminBar 2.0... (there isn't yet a thing called AdminBar 2.0, but who knows...)

Deane mentions ProcessWire on his recent blog post: http://gadgetopia.com/post/8219

Minor correction to above: The revision 99 holds the record with 3.870 downloads (published on thursday)!

WillyC's example just modifies the output of the $page->path() function (which is also used by $page->url). His intention there is to change what URL gets sent out when you call $page->url. It's really no different than making your own function and using it instead, except by using a hook like this, you can continue to use ProcessWire's API and get the result out of it that you want. Ultimately it's just a syntax convenience. While his hook example handles the URLs that get output in your markup, you still have to have something to look for and capture those URLs. Perhaps you could use mod rewrite, but typically you would use the "URL segments" feature that you see on the "URLs" tab when editing any template in PW admin. Lets use a simple example of your homepage template (home) with filename home.php. And lets say you want to make it so that when someone access domain.com/contact/ (a URL that doesn't currently exist) you want it to display the page that lives at domain.com/about/contact/. So you are setting up your site to respond to the shorter URL of /contact/ (rather than /about/contact/, where the page actually lives). Go to Setup > Templates > home > URLs. Click the checkbox to "allow URL segments", and save. Now edit your /site/templates/home.php file, and do something like this at the top: if($input->urlSegment1 == 'contact') { // render the /about/contact/ page echo $pages->get('/about/contact/')->render(); return; } else if($input->urlSegment1) { // throw a 404 throw new Wire404Exception(); } // otherwise continue normally and display your homepage.

If WillyC's suggestion is a viable solution and applicable for more use cases it would be great if stuff like this is documented outside of the forum. I, and i'm sure more people would have a hard time figuring this stuff out.

i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }

That's why I'm suggesting namespaces for version 3 - clearly there is no way changing all the class-names to using namespaces is going to be backwards compatible. Though on the other hand, I don't suppose it's unthinkable you could actually write out the class-name mappings from my tool, and derive an upgrade-tool that would rewrite third-party extensions and applications the same way it rewrites PW... I personally would worry less about upgrade paths - in my 14 years of experience, upgrading an existing application to a new major release of a framework is very, very rare. For the most part, it just doesn't happen - and major revisions should not sacrifice major improvements to support 5% of the applications that upgraded; most likely 95% of applications will be new applications...

Alright, I added support for the "implements" keyword and tweaked/improved a few other things. The code is here. The issues described above (as relates to the PW codebase specifically) still persist - I can't (won't, shouldn't) fix those, but they should be easy to fix by hand. This is currently set up for testing - it's "non-destructive", at the moment it won't write any files, just lets you preview the changes on a file-by-file basis, so we can evaluate whether this looks correct, or whether this approach is feasible to begin with. Let me know what you make of this? EDIT: posted some additional updates and improvements. By the way, currently the core classes are namespaced as "wire\core" and modules as "wire\modules"... this is simply due to the folder-structure. I started tinkering with a "remapping"-feature that would allow you to override the mapping of a folder to a particular namespace, but quickly realized that was a total waste of time, since you can just rename the actual folders. In other words, to change the namespace-hierarchy, just move files around or rename folders as needed. But my guess is, we're already happy with the folder-structure of WP? Makes sense to me anyway. I think it would be fine to separate the core from the modules entirely. Also note, in the last update I turned of namespace capitalization. I used to argue that a namespace is a name, in the same sense that a class or interface is a name, and therefore all should be capitalized. But lately I've changed my mind - unlike a class, interface or trait, a namespace is not a type, and I prefer the visual distinction between namespaces and actual types... EDIT: another update - the script now reports inconsistent class/file-names, and produces a warning when multiple types are declared in the same file. I would prefer to see PW3 comply at least with the PSR-0 convention of one type (class/interface) per file. And use regular *.php file-extensions rather than the esoteric *.module extension - smells like Drupal. If you must use a magical file-extension, it's better practice to use a double file-extension, e.g. "foo.module.php", designating that this is in deed still a PHP file, with a special purpose, and preventing accidental loading by an auto-loader. On the namespace issue, consensus among those I have spoken to seems to be, both camel-case and all-lowercase is equally acceptable.