ryan

This design direction is really looking good. It's as good of a replacement for the default admin theme that I've seen, and I think it could be a good direction for us. I agree with Antti, that I liked the reduction of the borders from the latest version. I did kind of prefer the icons in the page list actions, though am thinking it might be good to just have 3 configurable options there: text only, icons+text, or icons only. I think that the screenshots do demonstrate that a sidebar page-list is workable with condensed indents–it actually looks pretty great. But I'm not convinced it's workable on the technical side–I think we'd have to go with frames in order to avoid having to re-render that page-list on every edit. And even then, we run into issues, like when and how to refresh it automatically (like when a title is change for instance). Though I'm sure it's all solvable one way or another, and I think we should give it a chance and see where it takes us. Other elements that I think would be useful would be things that Soma has already done with his Teflon theme. One example I can think of is the drop downs that let you go straight to a template or field. I know the concepts shown here don't get down to that level of granularity yet, so just mentioning things I've liked. I know some people like the current minimal admin theme, and I am one of them (I can't seem to use anything else for more than a few minutes). But the default admin theme has to be one that markets us well, and apparently the current one does not have the broad appeal it needs to have. If there's one thing that comes up more than any other when people are checking out ProcessWire for the first time, it's a general aversion to the admin theme. This has been the case since the beginning. I don't understand it, but I think the current admin theme is the only thing preventing wider adoption of ProcessWire. There's a large segment of users out there that judge a product on how it appears to their subjective design sense, and they don't bother looking further if the admin look doesn't excite them. So what we need is something that draws people in rather than halts them from looking further. That's not to say that the current admin theme is bad (I quite like it myself), but that the current admin theme must be an acquired taste–something probably better as a 3rd party theme option rather than the default one. Diogo and I may keep using the current admin theme, but the time has come where we need a different default theme to increase our user base. There are several other admin themes that already exist that could accomplish this already. But like has been mentioned above (and by others before) there is also a need to optimize and improve some of the framework elements behind it all. So building a new default admin theme is best done with a little bit larger scope of changes than would usually accompany an admin theme. I'm not interested in switching away from jQuery UI, but would support inclusion of another minimal framework to provide more foundation both to grid and typography–the things that jQuery UI doesn't do, and isn't designed to do. I'm not sure what framework would be right, or if homebrewing would be better. Regardless, if we were to start developing a new default admin theme from scratch, I think Philip's design here is a good direction to build from. I don't have the bandwidth to get involved with this anytime particularly soon, but it should maybe be a top priority after release of ProcessWire 2.4.

I've committed an update that I think should fix this–please let me know if you still experience it. I wasn't able to duplicate exactly what you are talking about, but it was more just a matter of available time, and think I knew what the issue was. Just looking for confirmation that I fixed the right thing, but definitely found an issue that needed fixing either way. I'm not sure I understand the question/comment/request? I think it probably depends on the situation. But there are likely several scenarios that won't work when it comes to repeaters, because repeaters manipulate the field names behind the scenes, and both the definition of dependencies as well as the JS require the original field names to be in tact.

Your best bet is to use the API directly rather than trying to go it alone with the DB driver. Though the dev branch (and upcoming PW 2.4) use the PDO driver and you could certainly manage your own transactions in there if you wanted to. But I'm not sure you need transactions to accomplish this. I'm also not sure what sort of fatal error you are expecting may occur during the creation of your tree? But if the data in the JSON has non-unique page names with the same parent or something, then it's certainly possible. So one route you could take would be to build your tree within a try/catch and if an exception occurs during the process of building your tree, have your catch call $pages->delete($rootPage, true); to perform a recursive delete on everything that was created. Another strategy could be to just make everything (or just your $rootPage) unpublished during creation, and published upon success.

This one is tough for me to debug just because my access to IE is limited (I have no Windows PCs in my office). I also have a deep-seated IE-aversion, so usually need to be pestered a bit to use it. I'll ask my wife to bring her computer from her office, which does have IE (though IE10 I think).

Probably not. The URL itself would still have to be compliant with the standard URL character set, but the filename itself that appears on the user's computer could be different.

For efficiency reasons, Textformatter modules run from a single instance, so I'm guessing this is a side effect of that. I'll look into options for how we might get around the issue the next time I'm making updates to it. But assuming that 'body' is a rich text field and Hanna Code is the only Textformatter you had on it, you could probably get the unformatted version of it from your Hanna code and use that instead, to avoid triggering the circular reference (or whatever it's called). echo $child->getUnformatted('body');

I'm not sure about exactly what's causing it, except that I ran into it too at one time and fixed it on the dev branch. You can make the same change I did outlined in this thread or you can switch to the dev branch. Hopefully either should fix it.

Thanks, it looks like I've got a few more updates to make! Actually just checked, and it looks like I've already made them but just not committed them. Though a couple of those are actually just commented out versions of live() that have already been replaced. I keep the old commented version just because I find live() easier to read and comprehend what's going on. I'll go ahead and commit the rest here shortly. I'm running jQuery 2.x locally, with the migration plugin. I plan to include the latest 2.x jQuery with PW 2.4. I haven't yet found any others, though that might be because I'm still using the migration plugin to identify stuff that needs updating. But I'm not married to the fancybox plugin–we'll replace it with something else.

Nice work Horst!

Assuming this is what I think it is, see the fix in this post. I'm not exactly sure why this error appears in some instances, but if you apply that change (or switch to the dev branch) that will hopefully fix it.

It's actually delegated to InputfieldPage, which is an integral part of FieldtypePage designed primarily for the purpose of exactly what you are talking about: enabling you to select the appropriate Inputfield for your page references. It may look like there are hard coded class names in that module, but they are actually only defaults, fully dynamic and changeable in the module settings. You can add more Inputfields for page selection by going to the InputfieldPage module settings and selecting some more… this step is necessary when installing the module this thread is about. I don't know if there is an official name, but I've always referred to it as a transfer list or a multi-select transfer, as it enables you to transfer items from one to the other. I think your "swap lists" term describes it pretty well too.

404 pages serve an important purpose from an SEO standpoint. So if this is a public facing site, I'd recommend maintaining a proper 404 page rather than just redirecting to or displaying the homepage. You could always have your 404 page link to your homepage or even meta redirect to it after a few seconds.

The behavior is intended. When you change a field's type, it throws out everything about that field's configuration except what you see on the "Basics" tab. This is to ensure the field is starting fresh with its new type. I think it's safe and feasible that we could have it remember the tags too, but also don't want to introduce too much ambiguity about what is/isn't saved. So if we go that route in the future, the tags would get moved to the basics tab.

Which one do you mean? Most Fieldtype modules are paired with an Inputfield by design, and won't work with others. There are a few exceptions that do allow selection of different Inputfields. The Page reference one is a good example. But in order to limit the possibility that someone could break a field, you have to define which Inputfields are allowed from the InputfieldPage module configuration screen.

This module also adds a few options to your field's input tab:

Select Multiple Transfer Multi-selection Inputfield module for ProcessWire using the jquery.uix.multiselect plugin by Yanick Rochon. This Inputfield provides similar capabilities to asmSelect but in a very different way. The usage of two separate lists may be more convenient when needing to select a large quantity of items. Like asmSelect, it also includes support for sorting of items. Unlike asmSelect, it has a built-in search field for filtering. It can be used anywhere that the other ProcessWire multi-selection inputfields can be used. Download ZIP file Modules directory page GitHub Class (for auto-install): InputfieldSelectMultipleTransfer Important Installation Notes This module is installed like any other, however you will need to take an extra step in order to make it available for page selection. After installing this module, click to your Modules menu and click the core InputfieldPage module to configure it (Modules > Core > Inputfields > Page). Select InputfieldSelectMultipleTransfer as an allowed Inputfield for Page selection, and save. Now you should be able to select it as the Inputfield when editing a Page reference field. For obvious reasons, this Inputfield would only be useful for a Page reference field used to store multiple references. (Note that this video is showing this module in combination with field dependencies and dependent selects (something else brewing for 2.4 but not yet committed to dev).

Edit the line that it's talking about in Page.php and change it from this: if(!$template->hasRole('guest')) return false; to this: if(!$template || !$template->hasRole('guest')) return false; This change is also already present on the dev branch (I ran into the same error a few weeks ago).

Soma thanks for the troubleshooting here. I think we can solve both issues by having the LanguageSupportPageNames module hook into both $pages->saveReady() and $pages->saved(). It'll set an active status for all users/roles/permissions before one is saved, as well as record the current language setting. Then the $pages->saved() hook will restore that language setting. I will implement these updates later today.

Nice job Philipp, I like where you are going with this. Thanks for putting your time and skills towards this. Having a new default admin theme is something I think we need to approach soon, and contributions like this are very much appreciated. I also think your work here is nice to look at and very well designed. With regards to an always visible page tree: not showing the page tree when in the page editor is very much a conscious decision. I recognize there are benefits and drawbacks and that it's a compromise either way. Here's the thinking of why we currently compromise on the side of not showing it: The default admin theme needed to be something that could scale near infinitely, and delegating the page tree to a sidebar introduces a lot of natural limitations (though none that scrollbars can't solve, but I'm not a fan of them). Another goal was to keep the user focused on the page they are editing by having the browse and edit states be very separate things. Lastly was the issue of overhead: generating a page tree involves a lot of work, and can contribute to making the admin feel slow… especially if having to generate it for every page edit. (Though this may be something caching could solve, but it could be tricky to develop: clearing such a cache after each page save might defeat the purpose). I did actually test out both SilverStripe and MODX before developing ProcessWire–I wasn't pleased with their page trees and really wanted to differentiate ourselves from that. Though your design here for the page tree does do that–it looks a whole lot better than what's in other systems. Those are some of the reasons why we'd decided not to show the page tree when in the page editor. But I recognize there are some real benefits: I like the possibility of being able to quickly jump between pages when needing to make edits to multiple pages or needing to add a bunch of pages. I also like the aspect of seeing where I am in the tree… While the breadcrumb trail accomplishes it, the tree can reinforce it. But these benefits were not enough to outweigh the benefits of not showing it. Still, if there is great demand, or if people would prefer the option, I'd be supportive of it as an option in the default admin theme. Though do wonder if a full-width, click-to-reveal panel at the top of the screen would better solve the scalability aspect? Whether sidebar or top-panel, if these things open only when hovered or clicked, we could solve the overhead problem by just doing it with ajax. For the Quick-Add button, I believe we could easily support this on any templates that have family settings defining a single required parent. When templates are configured that way, they could have a checkbox that says "Add to quick-action list?" or something along those lines. Keep up the great work. I look forward to seeing more.

Thanks for testing Raymond. Just pushed a fix for this in the latest commit. Had to adjust the order that the operators were named in in the Javascript regex. You mentioned that your page field only holds a single page. As a result, the above can't work since it is asking for all of those IDs to match at the same time. Such a scenario would only be possible with a multi-page field. The OR syntax "|" in fields/values isn't yet supported for dependency selectors. I will be adding support for it, but not until everything else is considered stable with the dependencies. Basically, I'm trying to keep the number of variables at a minimum so that people can start using this stuff in a stable state sooner rather than later. You probably won't be able to do it exactly like that. But my plan is to let PW pre-process selectors to convert some things to page IDs before sending them to the Javascript side. For instance, you'll be able to do: d_product=/products/regioblad/ We might also be able to support: d_product.name=regioblad

I don't think it's possible to retain those filenames. ProcessWire converts file names to something that's universally web accessible, as well as compatible with the ProcessWire name format. It does this for both security and compatibility across servers. You could re-purpose or amend the description field as a filename and then use the wireSendFile() function with the 'downloadFilename' option to set to that custom filename. This way the file could be stored on the server in a compatible filename, while the file the user actually receives is named what you want it to be. It would take a little creativity and PHP in a template file, but if you feel up to it I can get you started.

It sounds like a potential bug in there, but I can't duplicate it yet. I've been dragging in lots of images, saving, etc. Any specific combination of factors you think might be involved (specific sorting actions, etc.)? What other 3rd party modules are installed? Any JS errors?

They work in 2.3.0 too, it's just that they are a whole lot farther along in 2.3.4 than in 2.3.0 (and more stable too). So if you are building a site around multi-language URLs, it's worth the risk of using a dev branch (IMO) relative to the benefits you get in this aspect.

Currently you can't pass multiline arguments to Hanna code. But I'm not sure how user friendly that looks even if you could. What I would probably suggest is to populate your content in a dedicated field on the page and have your Hanna code automatically look in that field. For example, your [col2] Hanna code might look like this: <?php if(!empty($attr['content'])) $content = $attr['content']; // use content attribute if supplied else $content = $page->col2; // otherwise pull from "col2" field on page // ...now $content is ready for you to use

You might try adding this to the end of your /site/config.php: $config->sessionName = "sevarf2"; session_name($config->sessionName); session_set_cookie_params(0, '/', '.mydomain.com');