ryan

@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

I haven't spent a lot of time at tutsplus, but get the impression the article is not consistent with what you guys expect from them. Maybe they are just testing the waters to see if there's any interest before investing more time into it? But the article should not have been titled "Introduction to ProcessWire", it should have instead been "A quick look at ProcessWire from a WordPress perspective" – I think the article would have been just fine with that as the title. What I do know about tutsplus.com is that it says Envato on it – a business that largely exists because of WordPress (?). So I'm not entirely surprised by the content of the article. If the choice is them writing something or nothing, I'll take something. The article left me with these impressions: If I'm a WordPress user that doesn't know anything about code, I'm probably not going to look at PW after reading this. But if I'm a full time, or hobbyist web developer that uses WordPress, this article is probably going to make me take a closer look at PW. From that perspective, it's alright. Maybe the article is lacking relative to what it could have been, but we are still better off with this article than without it. The article had a lot more good to say about PW than it did bad. I just hope that they follow through with Tweeting it to their half a million followers, which they've not done yet–we could really benefit from that. Yes there are a lot of Tweets about the article, but looks to be mostly just low-follower bots, and we haven't seen any real increase in traffic here from that. There wasn't a lot of blatantly inaccurate stuff like in that other WordPress-centric article from a year or two ago. I've only read it once so far, but the only thing that made me cringe was the word "mature" in quote "ProcessWire, and its lack of a mature theming model...", which I think is not the right choice of words because there is no theming modal by design, and that is one of the points of ProcessWire. The correct thing to say would have been "If you want to create a website without any development, use a ready-to-go theme with WordPress. If you want to develop a website and have control over the output, use ProcessWire." Hopefully they are just testing the waters and will publish a real introduction to ProcessWire… one where we can tell they've actually downloaded and installed it, and taken the time to learn a little and develop something in it. Or what they should probably do is hire someone like @teppokoivula to write an article for them… someone that already knows ProcessWire well, and knows how to communicate that.

I prefer to use PHP variables whenever possible. But there are some cases where it wouldn't be applicable or possible, like with a call to WireArray::implode(), etc. If there's an instance where you need to supply an output format (like with markup) before the variables are known/available, then the only way to do it is to {tag} it with placeholders. This is useful when providing an output format for something ahead of time that's going to be repeated over many times. For instance, the supporting markup for PW's Inputfield forms is generated in this manner, so that a module or core can specify the output format without having to get involved in the runtime rendering of the form. But it's not really a question of which strategy you should use, because most of the places where we support {tags} using variables isn't a possible alternative.

Good find @interrobang. Thanks for posting. I like how this narrows it down because before I would get every method of every API variable possible, which worked just fine, but this makes it even simpler. A couple of questions that I wasn't able to figure out from the linked page, and thought you might know: 1. How to make this apply to $this->wire() in the same way? (i.e. The wire() method from the Wire class). I tried to do it like this, duplicating the same properties, but no luck: \Wire::wire('') => [ all the same properties here ] 2. Also trying to figure out how to make it recognize a wire() or $this>wire() call with no arguments returns an instance of class ProcessWire. Any ideas? I'm not sure I fully follow what the '' == '@' means, the doc page is a little unclear, or maybe it's time to refill my coffee.

That's correct, you should avoid making edits to /wire/config.php. If you see something you want to change, then copy it from /wire/config.php into your /site/config.php and change it there. There's no harm in changing /wire/config.php btw, but anything you change there will get wiped out every time you update the core. That's why it's preferable to limit your edits to /site/config.php. There is no provision for adding custom properties under the "Core" tab of the config module, as the definition of "Core" in this case is properties that are part of the core configuration.

@ro-bo thanks for the detailed instructions. I was able to duplicate it after following the steps in those instructions. And @LostKobrakai was right that there was a missing getBlankValue in the sanitizeValue method. This week's PW dev version will include this fix at the top of sanitizeValue: if(empty($value)) return $this->getBlankValue($page, $field);

Great site Joshua! It really drew me in and I ended up reading a few articles there and started thinking "hey maybe we should move to the Yucatan someday". I think you guys totally nailed it, the site is an experience, felt native to the region, and your client must be very happy. I actually liked all the navigation options myself, though agree some kind of hover effect would be helpful. The only thing I'd mention here (beyond that I love the site) is that pages loaded a bit slowly from here in Atlanta. Run it through webpagetest.org, as it has a lot of suggestions that could make a big difference (especially setting expires headers on the image and css/js assets, of which there are a significant amount). The time to load first byte is also pretty high, which–if not something to do with server/bandwidth–indicates a lot of work is being done on the PHP/template file side, and enabling template cache or ProCache could make a big difference, even if you only use a 5-10 minute cache. Would you mind adding the site to our site directory?

What is the code you are using to send the notifications? Are we talking about JS code, or PHP code? I'm guessing PHP but just double checking. Would be good to see it in context.

@Can use the search engine in the admin to locate where it's finding those image references. For instance, I would do a "contains text" search for the term "pid36356-hidpi.png" and "13386630735_08db795401_b.jpg". Since the error is getting reported, the reference must exist somewhere, but perhaps it's on some other page loaded in memory that was triggered by something else (like another module, page reference, autojoin state, or something like that). Maybe the page is located in the trash? I'd also be curious what 3rd party modules are installed, and if maybe you've got the PageLinkAbstractor module installed (which shouldn't be, if using the content-type markup/html options with textarea fields). If you do have the PageLinkAbstractor module installed, don't uninstall it just yet, as I'd want to give you further instructions on how to convert things before you do that.

Thanks @maba, I'll look into this. Very possible that the extra actions just aren't yet hooked into the language-specific permissions, since both features are so new. But they should all be connected by the time both of these features are finalized. I'll put this on my @todo for the coming week though.