ryan

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.

Those should be translatable in /wire/core/Inputfield.php

Looks like I broke the dev installer with yesterday's commit. Sorry about that. It was just an exception that needed to be caught–PDO throws an exception in a spot where mysqli doesn't, so didn't think to add one. And now realize I must have had PDO's exception mode turned off when I tested. This is now fixed.

Thanks for the testing. I always seem to be thinking in PHP–looks like I needed to add some parseInt()'s in there (parseFloat()'s too). This should now be fixed in the latest commit. I'm curious to know if the dimension inputfield works with dependencies? I would think that it would not, given that there are multiple inputs and dependencies haven't been coded for multiple inputs on a single inputfield. But if it turns out to be working [after the last commit] that would be a nice surprise.

That's a bug! Thanks for finding it. Just fixed in latest commit. While I was in there, I updated the fields list in the template editor to display more information (labels and types). Thanks, glad that you are liking it so far!

Yep, I forgot. Just bumped it now, thanks. I've done very little testing with FormBuilder so far. I've really been focused on getting everything stable with the page editor context, before focusing on FormBuilder context. However, what works in one InputfieldForm should work in another. I did just test in FormBuilder and it seems to be working here (testing with checkbox field). First thing to try is in your preview window, right click within it and select "reload" (and do it again just for good measure). We want to make sure it's not a result of an old cached version of inputfields.js or inputfields.css. The one used in the page editor specifies a version number, which prevents that one from being cached. Whereas FormBuilder does not, so there's a good chance that Chrome just doesn't see the changed files yet, especially given that it's in an iframe. If it's still not working, let me know the type of dependency you are doing (including the selector) or just export and email me the form JSON and I'll import here to test.

I've gone ahead and committed the Inputfield dependencies to the dev branch, for anyone that would like to help test. I've also posted a documentation page that explains how and where to use them, current limitations and examples. There are a near infinite number of potential scenarios on how these things could be used, so it's not possible for me to test everything locally. As a result, expect bugs and please report them when you find them. Thanks in advance for your help in testing. For non-default admin themes, some updates have to be made in order to support field dependencies. As a result, unless you are an admin theme developer, it's best to stick to the default admin theme when using field dependencies, temporarily. Field dependencies can also be used in FormBuilder. Though I've not done a lot of testing in FormBuilder yet, so don't recommend using field dependencies in front-end production forms just yet. Though in my initial testing, they seem to work just fine. Thanks again to Antti/Avoine for sponsoring field dependencies!

It's basically a gettext style system (that doesn't use gettext) where the actual language represents the keys rather than a placeholder constant or variable. Anything you put in a __('Hello World'); function call essentially becomes a language constant (if I understand the term correctly). Even if you only have one language installed (default), you can still translate the text in the admin and have the output affected. The benefits in a single-language environment are perhaps even greater, in that you only need to translate the terms you want to change. It's a handy way to enable content management of static text. But I didn't design it, as it's the standard upon which most text translation engines work (most being gettext based). Regarding your module, is it possible for you to change the class and filename from "language_constants" to "LanguageConstants" or something else with the U&LC format? The reason goes beyond consistency: our modules directory and installers expect the format and other formats may cause technical issues.