ryan

I'm not entirely sure I know how to answer all your questions here because it sounds like you may trying to do things with InputfieldFile is may not necessarily be designed for. If that's the case, you may be better off extending it as a new PHP class, or copying its code to new module, rather than trying to achieve these all with hooks. Another thing I'm not sure about is whether you are talking about a front-end or back-end context. If dealing with a front-end context, the ajax uploading will not work. In some cases you may have to disable it on back-end use too (see the commented line below for how to do that). InputfieldFile is really meant to be used in combination with FieldtypeFile and within the page editor. But it is possible to use it outside of that context. Though you will still need to supply it a Page object so it has a known storage location, but the given Page doesn't need to have a files field. Meaning, it can be any Page, even an admin one. Here's an example of how you might use InputfieldFile on it's own: // page the file will be stored with (doesn't have to have a files field) $myPage = $pages->get('/path/to/your/page/'); // optionally set the name of existing file(s) that will be present (or leave it blank) $myFiles = array( $myPage->filesManager->path . 'myfile.txt' ); // file extensions you allow $myExts = 'pdf csv txt'; // -------------------------------------------- // create the form $form = wire('modules')->get('InputfieldForm'); // create the files field $f = wire('modules')->get('InputfieldFile'); $f->name = 'my_files'; $f->label = 'My Files'; $f->extensions = $myExts; $f->overwrite = true; // $f->noAjax = true; // uncomment if necessary $pagefiles = new Pagefiles($myPage); foreach($myFiles as $filename) { $pagefile = new Pagefile($pagefiles, $filename); $pagefiles->add($pagefile); } $f->attr('value', $pagefiles); $form->add($f); // add a submit button $f = wire('modules')->get('InputfieldSubmit'); $f->attr('name', 'submit_form'); $form->add($f); // ------------------------------------------- // process the form if(wire('input')->post('submit_form')) { $form->processInput(wire('input')->post); $pagefiles = $form->get('my_files')->value; foreach($pagefiles as $pagefile) { echo "<p>Your file: $pagefile->url</p>"; } }

@ragnarokkr it sounds like you do have page-permission in your system though? (Access > Permissions > page-publish) If that's the case, the user must have that permission in order to edit a published page. See here for more details: https://processwire.com/api/user-access/permissions/#page-publish

You can use "|" to OR fields, or OR values, but not expressions. Your selector is translating to something you didn't intend. I think the selector you might be attempting is instead this: template=event, enddate>=2015-11-06, enddate|startdate<=2015-11-13 Or you could use OR-groups: template=event, enddate>=2015-11-06, (enddate<=2015-11-13), (startdate<=2015-11-13) Either of the above selectors says: The template must be event. AND The enddate must be greater than or equal to 2015-11-05. ​AND (The enddate must be less than or equal to 2015-11-13 OR the start date must less than or equal to 2015-11-13).

Correct, if you've given them edit access those templates. With page-publish installed, that means the user must have that permission to publish any content to the live site. Editing an already published page enables one to publish live content. So that means they can't edit an already published page. That behavior is correct. On the other hand, they would be able to edit unpublished pages (or create them, if you've allowed that). Correct. That's what you'd want the hook for. Alternatively you could add page-publish permission for that role just to the "language" template from the Access tab of the template editor (see "Additional edit permissions and overrides"). But since you aren't otherwise managing access for the language template, I would suggest just using the hook function as the best solution. In that case, you'd want to modify the hook function to consider the language page-edit permissions: wire()->addHookAfter('Page::editable', function($e) { $page = $event->object; $user = $event->user; if($page->template == 'language' && $user->hasPermission('lang-edit')) { if($user->hasPermission("page-edit-lang-$page->name")) $e->return = true; } });

Aaron, PM me your FormBuilder key and I can reply with a snippet of code that will do it for you.

If you upload a random txt or html file to your web server, can you access it at the other domain? My guess is yes. If so, it sounds like an honest mistake. Perhaps you are on a dedicated IP and the owner of the other domain made a typo when setting up their DNS record. Or perhaps the web host made an error when setting up their VirtualHost directives in Apache. You should be able to correct the problem by adding this to your .htaccess file somewhere after the "RewriteEngine On" line: RewriteCond %{HTTP_HOST} !^www\.yourdomain\.com [NC] RewriteRule ^ http://www.yourdomain.com/ [L,R=301]

Good debugging work. The reason this occurs is because MySQL has a limit on the length of a return value from GROUP_CONCAT, though I think that limit is configurable in the MySQL server settings. The GROUP_CONCAT is only used for multi-value autojoins, so not something you need to be concerned about with large text fields or the like. Though with anything large, it's best not to use autojoin at all since it forces PW to load that data in memory every time the page is loaded. It might mean you could only load a few hundred pages in memory at once rather than a few thousand. Autojoin can be a nice optimization for things like "title" or a short "summary" field, or a blog post with category page references. But you would only want to use autojoin for a field that you know will always be accessed from a given $page, every time you load it, regardless of where you load it. For everything else you should leave it off.

Thanks guys, I've added an additional check for this. Regarding the use of a cropping string like "50%,40%" to the size() method, does this work? It doesn't seem to do anything for me. The capability is one that was added from a PR a long time ago, and one I've not ever had the occasion to use in production. But just testing it now, it doesn't seem to do anything at all other than return a resized image without cropping? The $options['cropping'] = '50%,40%' just resolves to a string of '50%,40%', whereas it looks to me like your intention is to provide an array to the size() method. Wouldn't it be better to do one of the following? // just provide a string $page->image->size(200, 120, '50%,40%'); // provide an array $page->image->size(200, 120, array('cropping' => '50%,40%'));

If page-publish permission is installed, it is required in order to edit already-published pages. I suppose we could override that for Language pages if the user has lang-edit permission, but not sure we should, will have to think about that one more. However, if you want to provide that behavior for your site, you could do so with a hook in your /site/ready.php file: wire()->addHookAfter('Page::editable', function($e) { if($e->object->template == 'language' && $e->user->hasPermission('lang-edit')) $e->return = true; }); I agree, I have committed a slight modification that enable this (now on dev). These changes are minor enough and restricted to one permission (lang-edit) that it doesn't affect anything else, so it's fine.

@maba turn off access control for the language template, as I think it may be interfering with the lang-edit permission. Next make sure that the appropriate roles have the permission "lang-edit" (which I think would include all of your translator roles?). They should also have "page-edit" permission in their role, but that role doesn't need to be assigned to the language template because the lang-edit role is superseding it. I also recommend using language page-edit permissions if you aren't already. Meaning, your main "translator-de" role should have page-edit-lang-de permission, your "translator-ru" role should have page-edit-lang-ru permission, and so on. If your "translator" role is the one that can edit default language, then it should have page-edit-lang-default permission. I also recommend assigning your translator roles page-edit-lang-none permission, so that they can edit non-multi-language fields, such as the site/core translation files. Also, don't rely on the "who an access this page" fieldset on the settings tab for this particular case because the lang-edit permission is superseding the existing access control (for language template only). This is similar to the user-admin permission. You'll want to test by logging in with one of the translator accounts.

Nope, it would give you the same copy that you already have. Unless something cleared the page cache between the time you loaded $page and the time you did your $pages->get(). PW clears the page cache after every save() or delete(), so if you found it was working in your case then chances are there was a save() that occurred after you loaded $page, but before you tried to retrieve $oldPage.

That's correct. PW tries really hard not to keep multiple copies of the same page in memory at once, which is why you have to make it force-reload a fresh copy from the DB if you want to know what the page looked like before changes were made to it.

I missed that. I read it as 2.6.17 for some reason. That 2.2.17 version should probably be upgraded.

In Martijn's hook, the $oldPage retrieval will return the same exact copy as $page, so it won't be possible to compare them since you'll be comparing the same page instance. What you'd want to do instead is retrieve a fresh copy of the page, then you should have two different instances of the same page to compare: $oldPage = $this->wire('pages')->getById($page->id, array( 'cache' => false, // don't let it write to cache 'getFromCache' => false, // don't let it read from cache )); I think you'll need the dev branch for this, as the 'getFromCache' option is not in PW 2.6.1 if I recall correctly. In 2.6.1 or earlier, I think that the following would work, but is not quite as efficient: $this->wire('pages')->uncache($page); $oldPage = $this->wire('pages')->get($page->id);

I'm assuming this is a Process module, since that's the only one that supports nav arrays. The arrays provided in your getModuleInfo (like the 'nav' array) are not called at runtime, instead they are stored in the DB. As a result, there's no reason to make those labels translatable–actually you should avoid it, otherwise the wrong language translation might end up stored in the DB. Instead, just make them regular strings like 'Enter Order' rather than __('Enter Order'). Then, somewhere else in your module, make them translatable. It can even be in a PHP comment. For instance, you could add this at the top of your module file: /* * __('Enter Order'); * __('Enter User'); * and so on... * */ These should be in your 'default' language. Make sure the phrases are identical to those in your 'nav' array. Doing this just ensures that the language parser knows they are translatable phrases. After making that change, do a Modules > Refresh, then go back and translate the file (Setup > Languages > language > your file), and save. Now it should work. If using AdminThemeReno, it won't work, unless you upgrade to the latest dev version. I just fixed that issue in AdminThemeReno yesterday actually. Since it looks like you are using Reno, you'll want to grab the latest dev branch.

Also look into using a /site/ready.php file, which will get called once the API is ready, but before any page rendering begins. The file receives all API variables, and you can put whatever you want to in it. There is also a /site/init.php file you can create, which does the same thing, but is called before the current $page has been determined.

@maba I put in some updates yesterday (dev branch) that may provide what you are looking for. After installing the latest dev, click to Access > Permissions > Add New. Click the section to add a new predefined permission, and add the "lang-edit" permission. Then add that permission to the role(s) that you want to be able to access Languages (Setup > Languages). If you are using language page-edit permissions (like page-edit-lang-default, page-edit-lang-es, etc.) then the user will also need to have the appropriate language page-edit permission in order to edit translation files for a given language. Please let me know how it works for you.

Marco, it sounds like the built-in static translation process should provide everything you need except for the permissions aspect. Setup > Languages > [language] > Translate New File. Point it to any file in /site/templates/ and you should be able to translate it. Let me know if I've misunderstood? As for the permissions aspect (limiting a translator to just one language), I can add support for our new language permissions to this static translation engine on the dev branch once we get 2.7 out the door. If you need it before that, you should be able to block access with a hook.

Exactly, this seems to be a point of confusion for people coming from those projects. ProcessWire is an entirely different animal, but sometimes people incorrectly apply their understanding of those legacy CMSs to PW. PW core (/wire/) is entirely separate from PW site (/site/). I want to be clear that when you build a site or application in ProcessWire that you can license your original works within /site/ however you want. We have been clear on that, but need to go further. The trouble is some perceive anything (like your own website) built in ProcessWire to fit that definition. You and I know it doesn't, but someone new evaluating PW for their own sites/apps doesn't. The 3.x is a branch of experiments, and the truth is I'm not totally settled on it, but figured I could be by next week. I'm still looking at LGPL a bit even if feeling it's a bit too ambiguous. If people think there are other alternatives we should consider to MPL 2.0 all feedback is welcome and everything open to change. Also just want to be clear that we're not making a commercial version of PW, that has nothing to do with this so that's not among our needs.

Ovi, I'm in agreement with Soma here that you need to try out a fresh PW install with no 3rd party modules to see if you can still duplicate the issue. If so, it would point to something with the server, since nobody else has ever reported a similar issue. Sometimes extra Apache modules like mod_security can cause strange stuff in this respect, so that would be something to ask ServInt to look at removing or disabling temporarily. But if you do have a default/unmodified PW installation reproducing the issue, and don't mind providing me access to it, I'd be happy to login and take a look to see what I can find.

This was going to be a topic for next weeks blog post, but maybe better here so I definitely welcome any feedback. The biggest factor is that PW is as much of an application framework as it is a CMS, even more so in PW 3.x. We can't be taken seriously as a framework on GPL v2. So we need to start licensing it like a framework, otherwise we risk projects excluding us on that basis. For instance, most frameworks (like Laravel) are licensed under MIT, as is jQuery. There's no plan for a commercial version of ProcessWire. I've already been there, that was Dictator CMS and ProcessWire 1.0, and not going back. We're wanting to go more open in order to gain wider adoption for the product, as well as just do the right thing for the community and best support the projects they build with PW. Following the old legacy CMS projects on license seemed to be a safe way to start, but now we seem to be the only new player using a license that preceded the existence of CMSs. So another factor is that, as we grow, that has been leaving too much ambiguity about where and how folks can use PW, and I'm aware of a recent big project that wanted to, but didn't use PW for that reason. I'm tired of that ambiguity and having to outline our interpretation, and what PW is and isn't. I'd rather the license did that for us and made people feel comfortable about using PW even if they don't totally understand what the product is. People that don't understand what PW is might interpret the license in such a way that they think anything they develop in PW (like their own web sites, templates and modules) has to also be GPL v2. This is false, and I'd like to get rid of that ambiguity. The MIT license is the most open and simple one, which I really like. But we've got a couple components (notably CKEditor) that won't work with that. So my thought was to make most of the PW framework MIT, but use MPL 2.0 for the bigger picture. The MPL 2.0 (Mozilla Public License) is a modern license that enables us to support much of the spirit of MIT while also being compatible with existing components like CKE. In terms of openness it sits in between MIT and GPL. From a framework perspective, it still lets you link any part of PW with applications under other licenses, which is what a framework must support. Under GPL we are only able support that linking with other code via modules and templates (the components PW is specifically designed to run) and that's just not enough to be taken seriously as a framework. There are other licenses like LGPL that might let us accomplish this too, but I still find LGPL too ambiguous for my taste, whereas MIT and MPL 2.0 seem to outline exactly what we're trying to accomplish as both a framework and CMS.

If you want to know the source of the error, edit your /site/config.php and set $config->debug = true; Then you should no longer get a white screen on error. Though the fact that you are getting a white screen indicates that maybe the error is occurring before PW even boots. Double check that you replaced your /index.php file with the new one from PW 3.0 as it is completely different (and about 1/4 the size) of the index.php from PW 2.x. I would guess that most likely your white screen is a result of the older index.php still being in place. But if you still get a white screen, edit your /index.php and temporarily add these two lines to the top of the file, after the opening <?php tag: ini_set('display_errors', 1); error_reporting(E_ALL | E_STRICT); Now you should see the source of the error. Those two lines are essentially what debug mode enables, but adding them directly in your index.php means you can get errors that occur before PW even looks at your debug mode setting. Please report back the error message you see.

BitDefender doesn't actually send out a request to the site, they are just reading from someone else's database–likely the same one as 360. No hidden iframes that I can find except for those coming from Facebook and AddThis (and there are plenty of those). The Facebook and AddThis scripts are kind of hogs, so you might see someday if you could replace any of those functions with Soma's SocialShareButtons module, which is really nice.

Looking at your homepage, I don't see anything suspicious either. Whether in the code, the network requests or the cookies. You would of course want to check things out deeper into the site, but usually automated exploits target the homepage. It's possible that the EMO code at the bottom may be creating a false positive, as base64 encoded strings are often used in exploits. In this case it's a completely legitimate use of base64, but that particular scanner may not be smart enough to tell the difference and seeing it as a red flag. The message you got also said "site was reported as..." which might just mean someone reported it by mistake or as a grudge or something. To be on the safe side I would run the site through another scanner that actually analyzes the requests, responses and output. But seems like a good chance it's just a false positive.

@ralberts, I haven't been able to duplicate the issue here. Though it will depend on what Fieldtypes these fields are using, so my test case may not be the same as yours. But I am wondering if you might be looking for field.subfield grouping to force match of the same record in a multi-value field? See here: https://processwire.com/blog/posts/processwire-2.5-changelog/#selectors-and-finding-pages For example, I'm thinking the selector you were wanting is instead this, so that "availability" is always referring to the same record in the set: @availability.column=1194, @availability.row=1889, @availability.value=1 More details here too: http://processwire.com/api/selectors/#subfield