ryan

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.

Just wanted to mention that neither of these are necessary. The CKEditor module already handles both of these settings. The enterMode is already hard-coded for ENTER_P. And you can disable ACF (i.e. allowedContent=true) by unchecking the "Use ACF" box in the field settings, which applies this.

Yes, it does work with Fieldsets. The first version doesn't work with tabs (FieldsetTab) though. I think this seems like a good idea Pete. I'll look into how best to implement in the next version. The first version I need to get committed to the dev source tomorrow (30th), so not planning to expand the scope of it this week, but moving forward, would like to continue expanding the dependencies system everywhere it makes sense. And your ideas here do seem like they could be very useful, and may not be very difficult to implement. Something to keep in mind is that dependencies are assumed to be things that can change during the course of filling out the form (i.e. if this field is populated, then this field is available, etc.). So when we get into things like user roles, we're talking about things that don't change during the course of the form. So these would be an entirely different kind of dependency. These would be dependencies that would be applicable before the form is actually rendered. They wouldn't need to be considered by the javascript dependencies at all. As a result, it really might make more sense for this capability to be something separate, at least from the code perspective.

When $config->pagefileSecure is enabled, the images on unpublished an non-guest viewable pages are protected by the .htaccess file. However, if you are on the dev branch and using this option, you'll want to comment out these two lines from your .htaccess file. They are meant to be commented out by default, but looks like they aren't currently on the dev branch. Only use the $config->pagefileSecure option if it is worthwhile to your site, because it is a little slower to serve images/files this way.

Asking for a page by ID is really specific, so it's not going to make you jump through more hoops than that to get at what you want there. If you know a page well enough to know the actual ID of it ahead of time, then it's not really a search/find at all. Regardless of whether you use get(123) or get("id=123"), ProcessWire can bypass the entire PageFinder engine (and any overhead associated with it).

The import data must have been entity encoded before import. It would probably be a good idea to de-entity encode it, so that it can be used in a rich text editor. You'd want to run it through something like this, once: foreach($pages->find("selector to find your imported pages") as $item) { $item->of(false); $item->body = html_entity_decode($item->body, ENT_QUOTES, 'UTF-8'); $item->save(); }

Horst, this sounds like a good way to go. As the resident image expert–what would you suggest is a good maximum for us to start with in a /site/config.php setting? I'm thinking we probably have to set something that would be compatible with a PHP 32M memory_limit setting. Though not positive we can really identify an exact number without trial and error. I was thinking of starting with 15,000,000 pixels (5000x3000), though even that may be too large.

It's important for there to be a hard limit on page numbers just from a caching perspective. You don't want to have anything in your site that can generate an unlimited number of cache files and fill up the hard drive. But that doesn't mean the limit has to be 999, just that 999 is what I perceived to be the upper limit of what would ever be even remotely practical to support in pagination. I'm fine with making this configurable though, but hope you guys use it to configure the number down rather than up.

Thanks Soma, I was able to reproduce it here too. Can you try out the fix I posted to the dev branch? You'll have to undo the page move you did before, and move it back again in order to get it to rebuild its index.

GomatoX, thanks for your module. Can you describe what language constants are and how users would utilize them? What would be the benefits over using the existing translation system or multilanguage page fields? I'm on mobile, but when I get to my computer I'll try it out and probably find the answer myself, but wanted to pose the question for the benefit of other users that may be interested.

Probably what is needed is a hook into the PageFinder class, rather than into the selector parser. If a value is wrapped in {brackets} like you mentioned above, a custom hook could be called. PageFinder is admittedly one of the more complex parts of PW, so I don't necessarily see any solution as being particularly simple to implement. But here is the function that deals with sort values in PageFinder if you are interested. I could add a condition in that function that calls a hook like PageFinder::handleCustomSortValue when it finds the value wrapped in brackets.