ryan

Adrian, it looks to me like you've done a beautiful job coding and documenting this module–nice work! I really like what I see here. I had once starting building a phone Fieldtype and gave up after discovering the crazy number of formats out there. So lots of respect to you for sticking with it and producing something complete and very well done here. Here are my only suggestions (minor): It might be nice to add a __toString() method to your Phone class, so when someone does "echo $page->phone"; they get a formatted (default) string. I'm thinking the country and extension inputs may not be applicable to all potential users–maybe there could be a way to turn them off? Related to input again, it's a little unusual (in my locale) to split out the components of phone numbers into separate fields. Though the coder side of me likes that you've done that here. But wonder if there might be some alternate input option that lets you populate it in one field and have a processInput that separates it out into the parts with a preg_split('/[^\d]/', $phone) or something.

The module's getCompatibleFieldtypes() function returns a blank array, meaning it's not compatible with any other fieldtypes (for the purpose of changing type). I did just test to be sure, but it doesn't let me change the type of a concat field. But then I tried to change an existing text field to a concat–now I see the issue. Ideally, it wouldn't let you convert an existing text field to a concat field. I'll have to think a little more on the best way to prevent that. I may have to modify the concat fieldtype to stop extending FieldtypeText.

It sounds like you might be running a version of ProcessWire prior to 2.3? It doesn't look to me like this jQuery multiselect plugin comes with any sort of pagination capabilities. I'm not really sure how they would do it, so kind of doubt that's on their roadmap, but will keep an eye out. At the moment, I don't plan to include this module in the core. Though if it's something that we find people will use on more than 30% of sites, then it would be something to consider. Okay I see what you mean there. Those two modules assume the "parent_id" to mean just the starting point (rather than both starting & ending point), which is why they are called out separately. I didn't think there's be much use for that feature beyond those two modules, but glad to hear I'm wrong–I'm sure I can find some other way to make that configurable.

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

I haven't had enough bandwidth to give it enough testing to commit to dev just yet, but attached are the changes I implemented earlier this week in an attempt to fix these issues. I don't yet know if they actually fix them or not. But if you have a chance to test it out, please let me know what you find. LanguageSupportPageNames.module

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