ryan

You should be able to link to any file whether an image or not. Are you saying that you can't link to it? Or are you saying that you want to display the image itself (rather than a link to it)? If you are using the TinyMCE image insert function, it's only going to allow you to select images from a field of type 'Image', and not from a field of type 'File'. If I've understood your need correctly, I agree with Apeisa that adding another image field is the way to go.

Try taking ProcessWire out of the equation for now and see if you can get any PHP tags to work in your Smarty templates. That might make it easier to troubleshoot why it's not accepting the PHP. Also make sure you are using full PHP tags rather than <? short tags ?> just in case they aren't supported by your server or Smarty. Is it possible that Smarty requires some specific syntax for breaking into PHP? My only other concern is if Smarty is handling PHP with eval() statements. That would probably create some problems. Still, it seems like it all might work once you can get Smarty to accept PHP?

Currently all 'viewable' branches are shown. So if you don't want a branch to appear, then you'd want to change the template it's using to be not-viewable by the user, via their role(s). You'd also want to set non-viewable pages to "not appear in listings" in the template's access settings. Not sure if that's what you are after, but just wanted to mention it as the PageList tree is supposed to be consistent with the users' view access, not edit access. With access being defined at the template level, I don't think we'd want to have it exclude non-editable pages because it would very likely prevent the user from being able to navigate to the pages that they can edit. Determination of view access is delegated to the $pages->find(), so it's handled at the database level rather than via any hook. Though I'm happy to add a secondary viewable() check before including the page in the list if you think it would be helpful? Or I could add a isListable() hook directly in the ProcessPageList or something like that. It would give you some flexibility to handle situations like the one you are talking about. It only uses the listable check on the page that initiates the tree. That's just to prevent a user from trying to get somewhere that they don't have access to by changing the GET vars to PageList.

I've added support for plurals and it works exactly as described here: http://codex.wordpress.org/I18n_for_WordPress_Developers#Plurals I've also added support for disambiguation by context, as described here: http://codex.wordpress.org/I18n_for_WordPress_Developers#Disambiguation_by_context At this point, our translation API is identical to that of WordPress both in function calls and arguments, so the WordPress i18n documentation is largely applicable to ProcessWire too. But WordPress relies on GetText and doesn't have built-in translation tools in the admin like we have, so I think we've got a much better system than they do for multi language support. To get the latest version, just 'git pull' it in. The only place where we needed plurals and contexts in the existing translated modules was in that ProcessPageSearch module. So if you access the translation screen for that module/file, you'll see a few of your translations listed as 'abandoned translations' and new inputs for the parts where we added plurals and contexts. Sorry to leave a few translations for you guys to redo in that module. I don't think we'll have to do this anywhere else. I'm thrilled that we've already got 3 new languages going in ProcessWire! Thank you all for your great work here! Nikola–thanks for the Croatian translation! It works great in my testing. Nico–the latest commit removes that text-transform: lowercase. I'm not sure why I had that there, but it's gone now. Slkwrm–It sounds like you have the LanguageSupport module installed and running, so I don't think it's a Git problem, and it sounds like you are on the right branch. I'm thinking it's more likely a file problem. Can you post a screenshot of your Spanish language screen with the list of translation files? That will help me to determine if it's a file issue. Thanks, Ryan

Thanks ggtr1138--that's great!! I look forward to trying this in the morning. Even though I don't speak the language I still love using PW with these language packs. it makes me very happy to see it running in other languages. Also, I'm glad to hear you guys like the built-in translation functions so far.

It looks like that Smarty app is definitely not PHP-strict standards compliant. You may want to be a little cautious with that app as it looks like someone wasn't using much care in the code. None of those notices are going to be a deal killer, but they are a bit of a red flag. Once you turn off PW's debug mode, they should disappear. But PHP is showing them to you because PW is putting PHP in a 'display all errors' mode. Uninitialized variables can be a little dangerous in PHP. But the good news is that we're not seeing classname conflicts between that app and PW, or anything like that... so I think you'll be able to get them working together (fingers crossed). Based on the fatal error that you are getting, I would bet it's as simple as a missing <?php tag before an 'echo' statement?

Good question. In this case, primarily because TinyMCE is GPL v2, and we include TinyMCE in our distribution. I don't think we can legally GPL v3 something that includes GPL v2 code unless that code's license is worded GPL v2 "or newer". Also, I am not very legal minded and there was a little bit of "go with the flow" and use the same license as WordPress/Drupal, which seemed like a safe thing to do. I couldn't find any GPL v3 licensed CMSs at the time I was figuring out how to license PW, so associated some risk due to the lack of examples.

Good find Nico. Plurals will be the next thing added.

Thanks for the feedback and testing! I'm not sure I understand "if loops", but your example makes me think you are talking about plural alternates? (like this: http://codex.wordpress.org/I18n_for_WordPress_Developers#Plurals) I had planned on adding those as soon as the need came up, but it hasn't yet. I don't know if it's just the way I've written it or if it's coincidence, but I've not come across any translation situations in PW where plurals would be applicable. Though I could certainly be missing something: let me know if you've found an example of one. I'm sure it'll come up eventually whether in PW itself or a module, so it's definitely coming. But I just wanted to find a place where it would be used before adding it.

Thanks Statestreet! Here is the most common and accessible way of doing it in ProcessWire (using $config->ajax). Your template that renders the ajax-loaded pages would look something like this: <?php if(!$config->ajax) include("./head.inc"); // include full site header if not ajax echo $page->body; // output all content here that is common to ajax and full version if(!$config->ajax) include("./foot.inc"); // inclue full site footer if not ajax Then in your site, output all the links with href attributes pointing to each page's URL. You might output nav like this: <?php foreach($pages->get("/")->children() as $child) { echo "<a class='ajax' href='{$child->url}'>{$child->title}</a>"; } From the JS/jQuery side, you would capture the click event on all class="ajax" links and let jQuery pull the content in and populate the container (called #content in this case): $(document).ready(function() { $("a.ajax").click(function() { $.get($(this).attr('href'), function(data) { $("#content").html(data); }); }); }); Using this method, clients that have JS/ajax support get the ajax version of the site. Clients that don't have it get a 100% regular and accessible non-ajax site. The only thing that you had to do was have your template check $config->ajax to determine if it was being loaded by ajax, and respond with the appropriate output.

Make sure you are using a new version of PW. Try turning on debug: /site/config.php - Find $config->debug = false; and change it to true. Hopefully we can get a better error message that way. See if you get an error when you do nothing but include("index.php"); (whatever the path to it is)

It sounds like you want publish_until to serve two purposes: as a toggle and as a date. I don't think you can have it do both, but here's a couple alternate approaches: 1. Leave the publish_until out of the selector and check it in your loop afterwards: <?php $time = time(); $matches = wire('pages')->find("status=unpublished, publish_from<$time"); foreach($matches as $m) if($m->publish_until > 0 && $m->publish_until < $time) $matches->remove($m); 2. Or; use two find()s: <?php $time = time(); $matches = wire('pages')->find("status=unpublished, publish_from<$time, publish_until>$time"); $matches->import(wire('pages')->find("status=unpublished, publish_from<$time, publish_until=0");

If I'm understanding correctly, I think you'd want to create your own template to handle the login, create a page, give it that template, and then set it to redirect to that page to handle the login. That way you'd have full control over how the login page is branded and presented. I believe there are one or two other threads that demonstrate how to create your own login templates, but let me know if you can't find them and I'll track them down.

It is! Soma shocked us all with it a few days ago–I'm loving it. Thanks, glad that you are enjoying ProcessWire! We are likewise glad to have you using it. Actually it is very much designed for that purpose. PW makes a great webapp back-end, and it's designed as much for this as it is a CMS. Though when it comes to complex user account interactions, it is more like using a framework than a turn-key system like the one we're typing in now (SMF). But PW has quite a powerful user system that is ready to handle just about any task.

Nice job Martin!

Welcome to the forums tsd! Thanks for your feedback. I've quoted and replied below: Coming soon. See Soma's 'Page Edit Soft Lock' module https://github.com/somatonic/PageEditSoftLock Coming soon. What you are describing is exactly how ProcessWire is designed to be used. But ProcessWire is a little different from any other CMS, so if you are in the mindset of another platform, try to look at it with fresh eyes. Don't feel wrong about it. A Page object is a data object and nothing more. It's what a Page is decorated with later that dictates what it's for and what it does. For example, a Page's template defines whether it's something that can be rendered as a webpage, not the Page itself. If a Page's template has no file, or if the Page's template has no roles assigned to it, then the page is just a lonely data container. There are a lot of different approaches that people like to use in managing their content tree. We try to leave all options open rather than dictating one over another. But the approach you describe is certainly possible now. However, best practices in ProcessWire are that it's preferable not to decouple your site's front-end and back-end structure. Doing so starts to use the tree as a bucket system, which is the system used by most other CMSs, and one we intentionally stay away from. But ProcessWire can be used as a very nice decoupled bucket system for those that need or want it (and I sometimes do), even if it's not a best practice. It's common to create a branch off the root to manage things like this. On the site I'm working with now, I have a /tools/ branch that is not a front-end page in the site, but a place where I keep components used throughout the site. For instance, /tools/ads/ has a collection of ads below it that the client can choose from to populate on various pages. The /tools/ branch is not a web accessible branch, but there are some things in there that I like to be able to render as pages. The ads I talked about before come in various formats: image, JS, Flash, etc., it could be anything. Rather than getting the other page templates involved in figuring that out, I let the ads render themselves (because the ad template(s) knows how). So I can do this to render a sidebar from my head/foot include, main include, or some other template: <?php foreach($pages->get("/tools/ads/")->children("sort=random, limit=3") as $ad) { echo $ad->render(); } So while there are times when you just want to pull some data and handle it, there are also times when you want to let the data render itself. If you limit yourself to data-only, you lose the choice and gain no benefit. Whether something is a branch or a tree doesn't really matter here from my perspective. The type is defined by the template, not the tree or branch. Any branch can be a tree. But if we start pulling branches out of the context of a common root, then we introduce a lot more complexity to the API. That's why we've been de-isolating other data containers (users, roles, permissions, etc.) and moving them to be part of the tree. Now all of these things are pages (in the admin branch) and they are a lot more flexible as a result. This is what ProcessWire is designed to do. If you can give me an example of exactly the output you are trying to achieve and where, I'll do my best with a structure and code example to better explain. I think code examples sometimes explain things easier than regular English can. Thanks, Ryan

This is great Nico! That was fast. Thanks for posting this. I just created German in my dev copy, dragged in your ZIP file and now I'm running PW in German! If only I could read it. It looks like it works great. Congrats–You are the first person to do a real translation for ProcessWire! How did you like using it? Any highlights or concerns? Thanks, Ryan

Sounds good–this has been added in the latest commit to the dev branch.

Soma this is awesome! Thanks for posting the video. Antti's right–you are on fire! I can't wait to give this a try.

Yes, you can do that. This is what's called a 'singular' module, meaning it returns a new instance on every $modules->get("MarkupRSS"). So you can create as many instances as you need, and they don't share data with each other.

Thanks for posting Statestreet. It sounds like a good and clever method to me, and I imagine it gives an nice app-like feel. Feel free to post a URL to it if you want. Like with anything ajax, you probably want an alternate/accessible path to pages if you want the content indexed by search engines, but I'm guessing you already know that.

I think this really just depends on what you are using to handle your modal dialog. Without knowing specifics, I'd say your modal dialog content should be set to an iframe pointing at your login page. And your login page should be output in a manner that looks good in a modal dialog (i.e. probably just the content area and not header/footer.

Soma, I'm not exactly sure why that would be happening, but it sounds like a possible bug in the system. I've not had it happen here before, so wondering how I can duplicate. Is there a specific module that you are using where it always happens?

Check your field settings for that page. Make sure that "parent of selectable pages" is unset. If set to 'home' then click 'change' and then 'unselect' home, and save. I'm guessing that's why it's only accepting pages with parent home. Likewise, make sure that "template of selectable pages" is unset (unless you know you want it).

Looks like I missed that headline on the Search page. Just added it to the latest commit. Once you've pulled in that commit, go to Setup > Languages > German and click the 'edit' link for the file for the ProcessPageSearch module, and you should see it there. Thanks for finding that and please let me know if you come across any more.