ryan

This thread is for the new PW admin theme being developed for 2.4. Zahari and WillyC, I'm sure you guys both have good intentions, but this is not the right thread to promote other admin themes and such. We're now focused on wrapping up and fixing bugs in the new theme, not redesigning it. This is in preparation for the very soon upcoming 2.4 release. Zahari–please do keep up the good work on your theme, post to the directory, and start a thread for it, as I'm sure many of us will enjoy using it too. WillyC–please don't let that one go beyond the sketch stage. I hope you can appreciate that there's no way one could ever get everyone to have the same viewpoint on subjective things, so that is kind of pointless. The goals here have always been more about the system. Then taking that system and reducing it to the most minimal, easy-to-use implementation. All while still incrementally improving on the old theme. The consensus has been that's what we've done, even if we're still working out some bugs. We'll let others take it and run with it in creating stuff more tailored towards their own preferences and other scenarios. The biggest complaints with the old admin theme were: 1) the colors don't have broad appeal; 2) the header area used entirely too much space; 3) the fields layout was too boxes-in-boxes with excessive linework, emphasizing the containers over the inputs; 4) the type was too small. The consensus and the math has been that the new admin theme solves these issues, while appealing to a broader audience than the old theme. Keep in mind there's no way to make everyone happy, so it's entirely expected to have a hater or two (I'd be more concerned if there weren't). Also keep in mind the old admin theme has a consensus of haters, among those that don't use it every day. So it's a bottleneck when it comes to new users. Is the new theme meant to be some kind of design masterpiece? Absolutely not–it is intentionally trying to avoid making design statements, and focused on reduction to essentials (though not to the point of looking like Craigslist). When it comes to the bigger design project (PW 3.0), we'll hand this off to Felix and Phillip (and perhaps others), who have already nailed the concept. That's my opinion, but we'll seek the input of the community to decide. My experience has been that small team design=good results, community/committee design=bad results. But that's another conversation. We'll move onto talking more about that once we've got 2.4 final. Regarding the Inputfield containers: yes there are still situations where the boxes-in-boxes (emphasizing the containers over the inputs) might suit an individual installation or preference better. But there are more where it doesn't. As a result, it's not as well suited as a default (and we've already been through this to excess), but it is something we always want to offer as an option. The new admin theme system allows for configurable spacing between the Inputfield containers via a setting provided to the InputfieldWrapper. We may even make it configurable within the default admin theme at some point, but I'd rather see other themes focus on things like that. As for the typeface: Arimo vs. Arial. I agree with most with the points about Arial, and I think the arguments presented here against using any webfont make sense. As much as I like Arimo and as good as it looks on my own computer, I think we've got to revert to Arial–it makes more sense with this theme's goals and in the big picture.

Also, make your "text", "date", "city" and "podcast" fields autojoin in your advanced field settings like WillyC mentioned. That should cut out a few hundred more queries as well. To avoid the nested loop, just keep track of when you need to output your headline. You want your data grouped by tour, so you'd sort by something from the parent, followed by the concert date. Perhaps "sort=parent_id, sort=date" in the concert finding query. Then keep a $lastParentID variable that you set at the end of your loop ($lastParentID = $concert->parent_id. At the beginning of your loop, check if $lastParentID != $concert->parent_id and display a headline when the condition matches.

There must be a lot of photos in there for the counting of that field to be a bottleneck? Something that may be even faster is to load the concerts that have photos in one query and label them as such, then load the concerts that have no photos in another: $concerts = $pages->find("..., fotos.count>0"); foreach($conerts as $concert) $concert->has_photos = true; $concerts->add($pages->find("..., fotos.count=0"))->sort("title"); Using that method, output code would just check $concert->has_photos; rather than count($concert->fotos); But you will have reduced 250+ additional queries down to 2.

Yes, every single repeater field has an associated template. Repeaters aren't designed to be used in this way (selecting repeaters from one page on another page), this is really more a use case for regular pages sans repeaters. Though I'm guessing that technically you could still do it if you needed to by creating a Page reference field that selects your repeater template with a custom selector like this defined in the field settings "template=repeater_something, check_access=0, sort=title", replacing the "sort=title" with whatever would be the appropriate field to sort on.

I've not seen this particular issue yet, but use CKEditor every day. There must be some combination of factors that causes it, but it's not clear what it is.

It looks like you are using http_build_query to build a query for $pages->find(). That's something you'd use to insert a query string in a URL, but it's not something you want to use for a selector. Instead, you'd want to sanitize selector values with $clean = $sanitizer->selectorValue($dirty); Though if you've already sanitized something as an (int) then it's not necessary to run it through selectorValue. For your 'sort' you'd want to setup a whitelist of valid sorts and validate against that. Rather than doing a "die()", I suggest doing a "return;" so that you pass control back to PW rather than terminating execution. To find only modified products since a particular date, you can include that in your find() query. Perhaps the client can specify "modified" as a variable to the web service. If they specified it as a date string like "yyyy-mm-dd h:m:s" then you can sanitize and convert it to a timestamp with $date = strtotime($str). Then use "modified>=$date" in your selector. To find which pages were deleted, the client usually identifies this by the non-presence of an item that used to be there. I also like to sometimes setup a separate "exists" feed that the client can use to test their IDs against. For instance, the client might query domain.com/path/to/service/?exists=123,456,789 and the response would be handled with something like this. It returns an array of TRUE for each queried page that still exists, and FALSE for pages that no longer exist. if($input->get->exists) { $dirty = explode(',', $input->get->exists); if(count($dirty) > 200) throw new WireException("You may only check up to 200 at once"); $ids = array(); foreach($dirty as $id) { $id = (int) $id; if($id) $ids[$id] = false; // set as not exists (default) } $results = $pages->find("template=product, id=" . implode("|", $ids)); foreach($results as $result) { $ids[$result->id] = true; // set as exists } header("Content-type: application/json"); echo json_encode($ids); }

Sounds like exactly the sort of thing modules are for. I'm always a little wary of overloading the core with too many options, so the primary test is whether something would be used by at least 30% of people. If so, then it may have a place in the core.

Just to follow up here in case anyone else ever runs into something similar: WillyC was correct about the issue here. It just needed to be an HTML HannaCode rather than a javascript one. Also wanted to mention I've posted an update to HannaCode, version 0.1.4 which fixes a couple of bugs having to do with the Ace editor. It fixes the issue where extra whitespace was getting inserted at the end of the code. It also fixes the issue where Ace sometimes wasn't active after doing a 'save & test'.

I think both of these issues are fixed on dev, but please let me know if you are still experiencing either.

Pete tracked it down and I put in a fix. The problem was actually related to the prependTemplateFile / appendTemplateFile options not being properly identified in the cache.

Actually I think all instances of $summary were supposed to be $text. Not sure what I was thinking, must have gotten a phone call in the middle or something.

Nice job Pete!

The root is the execution path, but ProcessWire changes it to /site/templates/ when executing a template file. Not sure exactly what would account for the difference here, but it looks like the different access control is resulting in one of the instances occurring while a template is being executed, and and another while it isn't. From within a module file, you wouldn't want to use relative paths like. You'd definitely want to use an absolute path to your resource. Lets say you wanted to include() a file that's in /site/templates/, you'd do this: include($this->config->paths->templates . 'your-file.php'); Or if you wanted to include a file in the current module's directory, you'd do this: include($this->config->paths->YourModuleClassName . 'your-file.php'); // this also works: include(dirname(__FILE__) . '/your-file.php');

You'd have to use the ID for the selector in this case. When no subfield is specified in a database-querying selector, a Page field will attempt to match the name or title of a selectable page if the given value is not numeric or a /path/. This is specifically for making it easier to do imports, like with ImportPagesCSV, where you'd be unlikely to maintain IDs in a spreadsheet. The reason it's not working in the above case is because the selector in question is not a database querying selector, just an in-memory one validating that the page matches the selector. Clearly it should in this case, and I think I can add support for this to the in-memory selectors. But I've been a little shy on this one because name and/or title aren't guaranteed to be unique in a set of selectable pages. So while they are convenient for things like importing, they aren't ideal for most definitions like this. Though the name is guaranteed to be unique, if the Page selection is limited by a parent. Roles is limited by a parent, so it would be fine in this case, but it could get you into trouble in other cases.

I see ProcessWire as a system that you build things on top of, and that's the purpose of it. You don't download ProcessWire to start publishing content in 5 minutes (even if you can), but rather to build a site or application. So ProcessWire is much more of a tool to accomplish some end means, rather than the end means itself. ProcessWire and WordPress are completely different animals in this area (opposites really), and I think it helps to explain why you can't assume that WordPress and ProcessWire would be considered in the same light via the GPL. I think the GPL is flexible enough to handle both. That's not to say we might not switch to MIT in the future, just to avoid even having to talk about it. But I prefer to stick with GPL at this time. When it comes to my own commercial modules, I still consider them open source for the users that have them, and any fees paid are for access to and support of the product. The 1-year timeline applies only to support. You can continue using the products as long as you'd like.

These are styles, not semantic elements. Most of the time, these are exactly the things you don't want your client editing. Determining these things is part of the design process and its the designers job to come up with a typographic system that maps styles to these semantic elements. It's not a limitation, but rather a great thing for the client and their content presentation. Here are the things the client should determine: paragraphs headlines and what level of headline (h2, h3, h4, etc.) bulleted lists numbered list emphasized text (strong, em) contextual links contextual images, if necessary block quotes, if necessary possibly others if called for by the content (definition lists, tables, subscript/superscript, etc.) Note these are all things that say "what" the content is, and not "how it looks". The client should know that when they input content, it will look good and consistent with the overall design system. The designer has already determined the sizes, colors, line heights, etc. for all of these things, and they are defined in the stylesheets. If the site goes through some redesign at some point in the future, all that existing content will be restyled without any edits to the content itself. If you can convince them of the benefits and to use it, then yes. It's hard to beat the long term quality and portability of content kept in markdown or textile. However, I think a well configured TinyMCE/CKEditor (configured to focus on content, not style) is preferable to most clients I've dealt with. You can change it to a plain textarea by going to Setup > Fields > body > details > Inputfiled type > select "textarea". I'm a little embarrassed to link to this because my website is so old and broken right now, but I think the content is relevant here: http://www.ryancramer.com/journal/entries/cms-design-longevity/ (keep in mind this is from 5+ years ago, and my site is a bit broken at the moment).

Your code for setting the language based on the domain looks good. It should be fast, and fine to include in every page. If you wanted to set it to the session, then you would just do something like this (though it's really probably not necessary): if($session->language) { $user->language = $languages->get($session->language); } else { // determine language from domain // ...your existing code here, then... $session->language = $user->language->name; } I don't understand the issue you've mentioned with the homepage. Since the language is being determined from the domain (rather than the path), it really shouldn't matter what page you are on. Is it possible that you've got your output code happening before your language-determination code? Reading your message again, you mentioned that you only had the language-determination code on your homepage? You should really put it in every single template, via a common include (perhaps using $config->prependTemplateFile option). Let the language be determined on every request, regardless of page. There's no guarantee that traffic will always arrive via the homepage, not to mention the potential SEO issues with assuming that.

I had experimented with text-stroke here too, but at least in OSX, it just made the text fuzzy. It didn't seem desirable at all, at least as a cross platform solution. Last I heard, Arimo was looking good on the PC at current font sizes? Is something like text-stroke needed to increase legibility on the PC? The text looks a little fuzzy in both of those examples in the screenshot (maybe from jpeg though), especially the one with the text stroke.

Teppo is correct. Fancybox has IE issues (though wasn't aware it affected IE8 too). You may want to switch to the dev branch if this issue is affecting you, though we are dropping support for IE8 in the new admin theme. In either case, you really shouldn't be using IE8, just for your own security and sanity. IE is now at version 11? Though I'd recommend going for Chrome instead if you can.

I'm assuming your entries have been converted to pages already. Try editing one of those pages and making sure that its category field is consistent with what you expect. If all looks good there, it just comes down to regular PW API selection of the pages that you want. In your case, if you wanted to list the pages in category 'mats' you'd have API code something like this: $entries = $pages->get("/submissions/")->children("category=1018"); Using the ID directly like that "1018" may be efficient, but isn't usually very readable, so you may prefer to use a selector like "category.name=mats" or "category=/categories/mats/" or whatever suits your particular case.

User creation is an administrative task, so if you need non admin/superusers to create users, you'd probably want to create your own form to do it. It would be relatively simple. Creating a user from the API is as simple as: $u = $users->add('username'); $u->pass = 'password123'; $u->addRole('example'); // optional, if role other than guest needed $u->save(); From the sounds of it, you don't want to create actual PW users, but maybe something like them using pages. You could certainly do this (perhaps mapping them all to 1 single PW user behind the scenes). However, I'd encourage you to use PW's users. There is a roles system that is designed to separate users, so the typical way to maintain this separation is by role assignment.

Regarding the page-publish permission, this is an optional one. Most PW installs simply don't need it. When there is no "page-publish" permission installed in the system (which is 99% of installations), it is assumed that if you can edit the page, you can also publish it. If clicking the "publish" button doesn't remove the unpublished state of the page, I would look to a potential database or server issue, as that particular issue has not been reported before this thread. Or as Teppo mentioned, it could be admin theme related (?), so it'd be worth testing out on the default admin theme to be sure. If the issue persists, please post your PW version, MySQL and PHP version and any 3rd party modules installed.

Make sure you have URL segments enabled on your "home" template. This is in Setup > Templates > edit: home > URLs. At the top of your home.php, you should then be able to have something like this: <?php if($input->urlSegmentStr) { $name = $sanitizer->pageName($input->urlSegmentStr); $category = $pages->get("/categories/$name/"); if($category->id) { echo $category->render(); return; } else { throw new Wire404Exception(); } } The other side of it is making sure that your category pages have their $page->path and $page->url calls represent the location you intend. You can do this with a hook. You'd want to add this in your /site/templates/blog.inc file. wire()->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath($event) { $page = $event->object; if($page->template != 'category') return; $event->return = "/$page->name/"; } Also for these examples, don't just copy and paste them. Go through line by line to understand how they work, as you may need to modify them specific to your case.

When you say that the editor doesn't appear, can you clarify? Does that mean you see nothing but a white page? Or maybe you see a plain textarea rather than a rich text field? Or just no field where there used to be one (as if it didn't exist?) Looking at the SQL error, do you know what language ID is 1160? I'm wondering if that might be your default language. It looks like you have the LanguageSupportPageNames module installed, just wanted to confirm? How many languages are installed? Do you have any other 3rd party modules installed? Lastly, you mentioned upgrading to dev, but do you know what version of dev? If you aren't sure what version, I may be able to tell if you know approximately what date you grabbed it.

I think that the date format has to have a delimiter somewhere (hyphen, slash, period or anything). ProcessWire assumes that a string of digits is a unix timestamp, so it's probably getting confused. I don't think we have a way of supporting a purely digit based date format. If you have that as your output need, you'd probably want to keep the date output format as unix timestamp, and then just use PHP's date() function on your front-end output.