ryan

Nice job Soma. I think you've done about as good as can be done with the type we're using. The truth is that we need a full rebranding pretty soon. The current branding was just quickly cobbled together by me a few years ago with little time or thought. And making logos has never been a specialty of mine. As the project has grown a lot since that time, we're nearing the point where we need a better presence with our logo... one that solves all the different scenarios at the beginning. Regarding typefaces, I love Avenir but have come to kind of dislike the Mahalia face. Though when it comes to rebranding the logo, we don't necessarily need to stick with any past typefaces.

Per @nik's request (from awhile ago), I've expanded support for the parent field selectors that you can use with $pages->find() and related functions. You can now pass those functions selectors like this: parent.name=about parent.name=about|contact parent.title*=Something parent.body*=Something|Something Else parent.title|parent.body*=Something|Something Else parent.template=basic-page parent.template|template=basic-page|fancy-page // and I think this is the one that @nik requested: parent.title|title*=Something Pretty much any combination of stuff can be used with the parent selector. Previously, you could only use id or path. As an added bonus, you can now also perform partial matches on a page name: name%=something name^=some name$=thing parent.name%=something parent.name|name%=something parent.name|parent.title|title%=something|something else These new features are available via the latest commit to the dev branch (upcoming 2.3).

Thanks, tested out and it works great! Very useful for sure--I like it! A few comments: Your init can hook "ProcessModule::execute" rather than "Process::execute". That would be a little more efficient. Having all the markup generated in javascript rather than your PHP (.module) file means that the text isn't translatable. Not an issue for me, but might be for some people that are using other languages. I'd suggest changing your <span class='notes'> to <p class='notes'>, just for consistency with the rest of PW. Looks good in your admin theme as-is, but in other admin themes the <span> runs up against the bottom border, whereas the <p> doesn't. Thanks for making this great module!

I think I'm finally caught up here after 6 days. This forum software doesn't always catch all the pending messages in the "view new content", so it's possible I'm still missing some. There's so much here I can't keep track of it all manually (though did try), so if you see anything that looks like I should have replied to it and didn't, please let me know.

This looks great! I can't to try it. Only problem is that it asks me for a login/password to download? Is this something we need to sign up for an account for, or is that an error?

I've not heard of that particular issue before. But 2.2.0 is now a fairly old version, so you may want to upgrade it to the current stable (2.2.9), just in case. Can you think of any changes that took place before it stopped working? What it sounds like to me is that PW does not fully see you as a superuser. The fact that you are getting that "you are logged in" message indicates it is detecting a lack of access to something and then sending you to the login page, and the login page is saying "you are already logged in". One thing you can try is to make sure you have the superuser role by adding it back from the API. Paste this bit of code into one of your template files and then view a page that uses it: $you = $users->get('your-user-name'); $you->of(false); $you->addRole('superuser'); $you->save(); Remember to remove it after executing it.

I wonder if there is some mod_security setting that prevents HTML5 uploads from working at some providers. That's the only thing I can think of.

Joss, thanks for making this. Looks and works great! I've been thinking that we need site profiles that originate in a few of the different frameworks, so this is really a great place to start. A few minor points of confusion I ran into: I can't seem to click to the "About this site" or "About pages" except on the sitemap page. The top navigation only seems to let me get to the "child page example" pages. The prominent "read more" button doesn't seem to link anywhere. I couldn't find an "edit" link/button anywhere on the front-end to case navigating between front-end and admin. Something up with the site settings template (see attached screenshot). I'm thinking those TinyMCE fields might just need to span full width. Though since you've got 3 identical fields, this might even be a good potential use for a repeater? Also on those TinyMCE fields, the text seems to be running up against the left edge for some reason (see screenshot). Not specifically a problem, but a detail I figured I'd mention while I was making this list.

Well admin themes are a type of module themselves, in that they are modular and meant to be swapped easily.

I've added the crop percentage stuff to the dev branch if you guys want to take a look and try it out. Admittedly, I don't totally understand all aspects of this or even how to accurately test it. I did also try to add crop by pixels support (which is more tangible to me) but am not getting the result I expect so kind of gave up on it. Let me know if you guys can figure out a way to make it work. To crop by percentage, do it like this: $img = $page->image->size(400, 300, "50%,30%"); To crop by pixels (not currently working quite right) do it like this: $img = $page->image->size(400, 300, "100,100"); When doing testing or debugging, I recommend preceding your tests with a $page->image->removeVariations() call. I was testing with something like this: $img = $page->image; // remove any previously generated sizes, crops, etc. $img->removeVariations(); // output original echo "<p>$img->url<br /><img src='$img->url' /></p>"; // make crop $img = $img->size(400, 300, "50%, 30%"); // test crop echo "<p>$img->url<br /><img src='$img->url' /></p>";

Looks great! Thanks for making this admin theme. Some really nice details in there too. Please add to the modules directory at your convenience: http://modules.processwire.com/add/

I actually saw a DeLorean up close for the first time last week, in Orlando, FL. Drove out of a parking spot right next to me. Was surprised at how good looking the car actually is, and a lot lower to the ground, and not nearly as dated looking as I would have expected.

I think you'd probably want this, or something like it: if($input->urlSegment1 && $input->urlSegment2) { // URL has /category-name/post-name/ $postName = $sanitizer->pageName($input->urlSegment2); $post = $page->child("name=$postName"); if(!$post->id) throw new Wire404Exception(); $session->redirect($post->url); } else if($input->urlSegment1 === 'rss') { $homepage = $pages->get('/'); renderRSS($page->children("limit=10"), $homepage->get('headline|title'), $homepage->get('summary|meta_description')); } else if($input->urlSegment1) { // URL has /category-name/ $categoryName = $sanitizer->pageName($input->urlSegment1); $category = $pages->get("/categories/$categoryName/"); if(!$category->id) throw new Wire404Exception(); $session->redirect($category->url); } else { // display paginated blog list $headline = $page->get('headline|title'); $content = renderPosts("limit=10", true); include("./main.inc"); }

Thanks for your efforts here. I think it looks a whole lot better than the Underground logo. And I think they are plenty different enough, so that's not a concern to me at least. What is a concern though is something that Diogo brought up when I'd done something similar (though not as pretty as yours). He mentioned that the uppercase Avenir P by itself looked like a parking sign, exemplifying standing still rather than moving forward… something we probably don't want to communicate. Once he mentioned that, I couldn't un-see it either. Though maybe we're looking too far into it, and I'd be curious what others think.

Form Builder doesn't get involved with individual fields (other than a custom files field made for it). So it will reflect whatever behavior is provided by the Inputfield modules installed on your system. I'm not aware of any Inputfield modules that provide the capability you mentioned yet, but it's certainly feasible. Multi-page forms are not currently supported, though on the roadmap. Some basic conditional logic will be added to ProcessWire's Inputfield system within the next couple of versions, so Form Builder will inherit the same conditional logic at that time. However, it is currently possible to support conditional logic on your own with javascript manipulation of the form. There are several instances in the PW admin where this is being done with Inputfields already.

Best bet is to delete the files you intend to replace by clicking the trash icon and then save. Then upload the new replacements.

ProcessWire is a content management framework, which is still a "framework", but more focused on a particular thing. Whereas the framework scope of CakePHP, Laraval, CodeIgniter, etc., is more broad and cover more territory. ProcessWire isn't meant as a replacement for one of those frameworks, but I think there are probably many instances where its focus might make it preferable. And an equal number of instances where the opposite is true as well. There's also something to be said for bringing the two together in some instances. Another big area of difference is that traditional frameworks enforce a particular approach to build on top of, whereas ProcessWire aims to be a lot more transparent, like jQuery. Frameworks set you up with a place to put your models, views and controllers, whereas ProcessWire puts in you in a plain PHP file (template file) that is given a location context ($page) and lets you take over from there. We think MVC is a good approach to take with ProcessWire template files, but don't enforce anything, as it's up to the developer. For better or worse, the possibilities are wide open in the same way they are with a PHP file on its own… though with a full CMF API at your disposal.

Sounds good, I am putting this in 2.3 and should be on the dev branch later today. It will look for a file /site/templates/errors/500.html and use it when present.

Another factor to consider with the current solution is that it depends on an autoload module (executed on every request). That's a little less efficient than a solution that is specifically called upon when needed, as an Inputfield would be. From that respect, it would probably make sense for this to be InputfieldTextareaCounter. It would also be the simplest and most straightforward to implement and maintain. The drawback would be that you couldn't apply the counter functionality to other types of unknown future textarea derivative inputfields. But if someone is making a new text inputfield, chances are it's like TinyMCE, ACE editor or some other type of thing that wouldn't be compatible with the counter anyway. Ultimately the functionality provided here is pretty darn useful regardless of how it's implemented. But if I were implementing it myself, I'd probably make it an Inputfield rather than an autoload module. As a bonus, this would also guarantee compatibility with non-admin Inputfield forms, like those from FormBuilder, FormTemplateProcessor or API generated Inputfield forms.

I don't know of a way to have ProcessWire keep track of two separate template directories. But of course you can turn any template file into a controller for any number of other template files and include them from wherever you want. A simple example would be to create a template called "external" and add a text field to it called "external_file". Then in your external.php: <?php if($page->external_file) { $filename = "/some/external/path/" . $sanitizer->name($page->external_file) . ".php"; if(is_file($filename)) include($filename); else echo "$filename does not exist"; } else { echo "No external file defined"; } Rather than external_file being a text field, it'd be better as a page reference field connected to a <select>. That way you could select your template rather than having to type it in. But I wanted to keep this example as simple as possible.

Thanks Joss, this is really coming together very nicely!

If switching the salt to 22 digits fixes it, I'm all for that! I'll make this update. Thanks again for all of your research and testing there. This is interesting, it seems like your web host must have sessions configured to do something different than usual as PW has no memcache implementation for sessions yet. You might try installing the SessionHandlerDB module that comes on the dev branch to see if that resolves it. Your session_start(); at the top of index.php may be leading to other less apparent problems, so I would try to get it working without that if you can.

If one had a big enough security hole in the site where someone could actually execute SQL queries, then that's something that probably needs to be fixed quickly. Seems like trying to hide the table names is a good way to let a security issue drag on and perpetuate. I'd also worry that having such a feature in place would make developers assume they weren't fully responsible for their own security and could half-ass some code because "the random table names will protect me." Then again, if I was running WordPress or Joomla, I'd probably want all the security through obscurity I could get. I doubt the problem is the CMSs themselves, but the plethora of insecure plugins and themes. I suspect the masking of table names is in response to an existing problem with those. Still, it seems like this approach does foster an ecosystem of insecurity. If that wasn't a security "feature" then the bad plugins would get cast aside a lot sooner and the whole ecosystem would probably be more secure in general.

Thanks that definitely looks interesting and useful. When we comes to these API functions, we're basically blind, so the cropping functions are really about trying to ballpark an area. We assume you may have a "group of images" context, but not a single image context. For instance, say you've got an employee directory containing a vertical head shot photo for each person. Then lets say you need square thumbnails for a listing page. In these thumbnails, you'll want to gravitate towards the "north" so that their head doesn't get chopped off. For other situations where you aren't blind and do have a single image context, then I think Apeisa's thumbnails module is the best way to go. Though the next step with the API may be to add more pinpointed cropping functions, but I suspect they will really only be useful for people developing a front-end to them for cropping individual photos.

Thanks for the follow-up on this. Those two statements should be equivalent and produce the same result. So if they aren't, then sounds like I need to do some bug hunting.