ryan

Looks like we've got a bug here on the dev branch (if that's what you are running?). First, update to the latest version of the dev branch. Then edit your /wire/core/InputfieldWrapper.php and add this line as the first line in the getChildByName() method: if(!strlen($name)) return null; Does that fix it? I think it will, but am not in my office to test yet. I can't yet find any indication of why this wouldn't work, and have it in use on a few sites. Make sure your dev version is up-to-date. Also make sure that you don't already have a "custom PHP code" or "custom selector" specified that might be overriding your template setting. If you still can't get it to work, let me know and I'll attempt to reproduce when back in the office. Another way you can get the same behavior would be to use the "custom selector" and specify "template=your-template".

I agree, sounds very interesting. I'd be interested to know if anyone gets the chance to try this. You are right that if it runs WordPress, it should also be able to run ProcessWire... assuming they haven't built it around WordPress or something.

A ram cache is something completely different from ProCache. ProCache takes dynamically generated ProcessWire pages and converts them to static assets, so that they can be served directly by Apache (bypassing PHP and MySQL). Though that's the easy part. The biggest job is managing when those assets get deleted and/or re-created. Files like images, JS, CSS are already static assets (usually). I could be wrong, but I don't think that the hard drive is usually a bottleneck on most web servers. So I'd think minification and optimizing your client-side cache settings in htaccess, and then considering a CDN would be things I'd probably look at before a ram cache. ProCache is going to deliver the biggest performance benefit over any of these though, as it is minimizing or eliminating the biggest bottleneck on a dynamically generated site (PHP and MySQL).

Try to disable pagefileSecure in your /site/config.php: $config->pagefileSecure = false; Most likely the Apache htaccess rules that make that option work are not compatible with nginx (or require a different set of htaccess rules).

Kyle, I'm not familiar with Vagrant but looked it up and it looks interesting. Is it possible that it's interfering with variables $_POST or $_SESSION? Also, when on that login page, does your URL address bar have a trailing slash or not? (it should, but double checking). You might also try disabling session fingerprinting in your /site/config.php file $config->sessionFingerprint=false; I'd also be interested to see what's in your phpinfo if you want to paste "<?php phpinfo();" into a file and view it in your browser.

Yes, I'd be happy to do this. I didn't realize it was that simple. I've got some other things on the to-do list first, so if anyone gets to it before I do feel free to send over the files and I'll add them when I get back in the office next week.

The "Geocode OFF" text is what is shown when the checkbox between address and lat/lng is not checked–make sure you've got that checked, unless you want to manually input your own lat/lng coordinates.

The goal is that there would be no difference from our perspective. But the reality is they are two totally different things behind-the-scenes, so there are sometimes minor differences. In time, hopefully there won't even be minor differences. But either way, it's good to know the difference just because database-querying selectors are more expensive to execute in terms of resources. Any function that accepts a selector and returns pages from the $pages or $page API variable is a database-querying selector. Whereas in-memory selectors are primarily used by PageArrays, as they represent a group of pages already loaded in memory and selectors are used to filter through them. $results = $pages->find("selector"); // database-querying $results = $results->find("selector"); // in-memory $children = $page->children; // database-querying $children = $page->children("selector"); // database-querying $children = $children->filter("selector"); // in-memory $children = $page->children->find("selector"); // database AND in-memory (just use children w/selector instead)

I can confirm, this doesn't seem to work for me either. I'm not yet sure why it doesn't work, but will look into this. Currently dependencies can't check if there are options available in a selection field... it can only tell if something is selected and what is selected. I'm not really sure how I'd suggest solving that particular issue, short of a custom module. But for starters, it might be good to set the visibility state of the field to "collapsed only when blank", which should help to keep it out of the way until needed.

Sorry for not finding this discussion earlier. It sounds like the issue is already resolved, but I'll just add a couple minor points. Multi-language support is something that is installed by modules rather than something that's in the core from the beginning. As a result, the "default" language is the one you would have if you had no multi-language support installed. Likewise, the content of the default language is the content that would remain if you later uninstalled language support. So you need to think of that default language as the foundation or core language of the site. Once you start using multi-language fields, you can't easily swap in another language as the default (at least not without copying/pasting or making a little scripts to move things for you). If you needed the ability to do that, then you'd probably want to consider your 'default' language as unused on the front-end, and delegate all of your languages to non-default languages. I think it would be perfectly fine to consider the "default" language as "no language". When editing a page, you'd still be left with placeholders for the default language, which you'd probably just consider to be notes for the admin. The default language homepage is always represented by the root URL, "/", regardless of what name you've given it in the homepage settings tab. This is to ensure that a user arriving at your homepage doesn't encounter an immediate redirect to /en/ or /de/ or the like. Redirect from homepage is a behavior frowned upon by search engines, and generally considered a bad practice regardless. So ProcessWire is coded to prevent an automatic redirect from occurring on the homepage. That default language name comes into play on the rest of the pages in your site. If you wanted your homepage to be nothing but a language gateway (with no default assumed) then you'd need to delegate your real default language homepage to a separate page, like /en/welcome/ or something like that, which your language switcher can link to.

I think this is most likely the case, assuming you do have multiple render() calls. Your _init.php may not be the right place to do some of this stuff, or if it is, then you may need to add additional check so that you don't have the same things being run twice. For instance, you have a $config->scripts->removeAll(). If you add some scripts to $config->scripts, and later have another $page->render() call, then the files you previously added to it would again be removed by your $config->scripts->removeAll(). There are a couple ways you could solve this. First would be to just move your code that shouldn't be run twice to a separate include file, and then use PHP's include_once() function on that file. For instance, your _init.php could have this: include_once("./_init_once.php"); The above is the safest bet, because if your _init.php defines any functions or classes, then you don't have to worry about them being defined twice (and resulting in a fatal error). But if you want to keep everything in your _init.php, you could do this: if(!defined("LOADED")) { define("LOADED", true); // your code here // ... } Lastly, I wanted to mention that your files will have access to an $options variable, which has a 'pageStack' property containing a stack (array) of pages that initiated the current render. It will be empty the current render() is not recursive. So you could accomplish the same thing as above like this: if(empty($options['pageStack'])) { // your code here // ... } One more thing I just remembered is that you could also tell your render() call to skip the prependTemplateFile: echo $somePage->render(array('prependFile' => ''));

Thanks, I'll take a closer look again to see if I can reproduce. Did the 2nd installation also have multi-language features installed? Can you think of any other factors on the page's being cloned? (i.e. is it a clone of a page with children or no children, etc.)

For the file download, you can also look at the wireSendFile function. It sounds like you found the DB export functions from the profile exporter. For the importer, have a look at ProcessWire's install.php file that can do an import via mysqli or an import via PDO but note that it doesn't work with just any SQL file, as it requires the simple SQL dump produced by the profile exporter (i.e. single line statements and single record INSERTs).

I agree that it does sound like unnecessary duplication. What's the benefit of creating your own users as pages separate from ProcessWire users? I'm not sure I understand the considerations there yet. But if you want to go that route and create your own pages as users, then there's probably no reason to maintain a 1-to-1 mapping with PW users. Instead, you can probably have a single user that you map all your own user pages to. Or perhaps a few separate PW users that you can map to, each with different levels of permissions... but then this is treating PW users as roles or groups, circumventing a system that's already there. I think the question of what users are may be the wrong question and instead it might be better to look at using the existing users system and what management additions are needed in your case. Perhaps modifying or extending the current ProcessUser module to provide the capabilities you need would be the simplest route.

Just want to mention that the module in question is filed under the proof-of-concept category, which means: Maybe there is some question as to whether we should even have this category, especially as the modules directory grows. I would also like to have dedicated modules managers (people) to ensure the quality and ongoing compatibility of modules in the directory. The current scale is beyond my own ability to keep up with on my own, but a team of us could do it. Soma, you would be my first choice, especially given the number of modules you've created–especially the highly-relevant Modules Manager. The current ratings system in there is meant to be a bit of a crowd-sourced solution, where the best modules also have the most "recommendations". But having a bigger QA team would be far preferable as a primary solution.

It's not necessary here, as ProcessWire doesn't include the http host with url() calls... just the path. So you can prepend the http host yourself, or make a custom function to do it for you. For example, you make an uppercase "URL" property to refer to your own version: wire()->addHookProperty('Pagefile::URL', function($event) { $event->return = "http://www.domain.com" . $event->object->url; }); Usage: <img src="<?=$page->image->URL?>">

It probably is possible. It's going to use whatever database is defined in your /site/config.php or /site-[n]/config.php file, so that's pretty much all there is in terms of defining what database is going to be used.

It looks fine to me. I would just add a check that the $img exists, before outputting it in your $portfolioGrid variable, i.e. if(!$img) continue;

Most likely something with mod_security. Try creating a template that has nothing but a 'title' field, then create a page using that template and save. I'm guessing that'll work, because the POST has no HTML in it. Some hosts using mod_security just aren't friendly with rich text editors, especially multiple instances on the same submission. You'll want to ask your host how to disable mod_security.

No problem, here it is

The code looks fine to me. I would double check that you've got all the right field names in your code, typos, etc.

Sorry, I thought we were talking page fields here. If limited to the fields in template/field (or module) settings, then I know what the issue is. It's the encode/decode process, which attempts to detect and enforce numeric types and empty values. Best way to bypass that is to put something non-numeric in there. For instance, for a color value something like #000 rather than 000 would likely resolve it. Though I may also be able to have it skip over digit strings that start with a zero and have no decimal.

I'm not seeing this behavior with Text/Textarea fields. Just tried in a few spots. Any other factors you can think of?

It would be a security risk, which is why ProcessPageSearch only works from the admin side. However, if you grab the ServicePages module, that essentially gives you a safety net/mediator between ProcessPageSearch and your front-end.

Just in case anyone was wondering why I've been silent for the last week, it's because I've been away on vacation, so have a lot of catch up to do here (didn't have internet access while I was gone). Just got back last night, and it seems my hands have to re-learn how to type. When I click on "view new content" I have 9 paginations of unread messages–ouch. This is probably going to take me a week to get through, especially with the Christmas holiday here. But I've been anxious to get back into the swing of things here and looking forward to getting focused on PW 2.4 now. Because I'm behind on the messages here, if there is anything urgent that you know of waiting on me, please reply or PM me and I'll make sure to get those right away. Thanks to all of you for taking good care of the forum while I was gone. Also Merry Christmas / Happy Holidays to everyone.