ryan

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');

It looks like the ProcessPageDelete module uses a jQuery live call, and live() was removed from jQuery. They found a better way to do it, but I still miss the more-straightforward-to-use live() calls. We had to change all of our live() calls to on() calls in the core a version or two back. So I think Nico probably needs to do the same thing in this module.

What address are you attempting to geocode? MapMarker does both server-side and client-side geocoding. When you type something into the address, click anywhere else (outside of the field) and the Javascript geocoder should populate the latitude/longitude. If that is successful, it won't attempt to use the server-side geocoder when you save. You can disable geocoding by checking the box that exists between the address and lat/lng fields. If you only enter latitude/longitude values (whether entering the values directly or dragging the map marker pin), then it will attempt a reverse-geocode, which means it will attempt to find the street address for the coordinates. If you are dealing with an address (or coordinates) that Google Maps doesn't recognize, you may just want to disable the geocoder by unchecking the box. But I get the impression that neither the JS or server-side geocoder is working in your case, and that perhaps Google's geocoding service is blocked for you or something?

Namespaces actually won't solve that particular issue unless someone opts to create their own namespace in their template file. That's something they could do now if they wanted to. So the switch to namespaces in PW's core won't change anything in this regard. If they want to overwrite a locally scoped API variable with their own, they will still be able to do it. I haven't updated the roadmap yet, but i'm slating namespaces for PW 3.0 rather than 2.4. Namespaces are going to require all modules to have "namespace ProcessWire" at the top. Either that, or use long/ugly syntax to access PW API calls. Likewise for template files (though I'm hoping to find a way to abstract that to compiled templates or something, so folks don't have to do this unless they want to). Once a module is updated for namespaces, it won't be compatible with previous versions of ProcessWire. Basically, it's all and a bigger and more annoying change (for most users) than I originally thought. But it's still a necessary one. Given the lack of compatibility for modules, I think it all needs to be tied to a larger version number like 3.0. Though if all goes well with the pre-compiled, auto-namespaced template file option I'm working on, then theoretically it could be applied to modules too. Such a solution would be applied to template files/modules that don't set their own namespace. That may enable us to add namespaces in the 2.x version tree, but I'm not confident enough that this solution will work in full just yet. I'm actually already working on 3.0 and have been for some time, so it'll probably be the next version of ProcessWire after 2.4 or 2.5, regardless of whether it ends up being 3.0 or 2.5, or 2.6.