ryan

I think you are on the right branch, because you wouldn't even have the LanguageSupport module if you weren't. But if you want to double check, you would go to your command prompt, and do this: cd /wire/ (or wherever you have PW installed) git status The first line it outputs should say this, indicating the dev branch: # On branch dev While you are there, try typing this, just in case you've got a version that was missing something: git pull If that still doesn't do it, I'd suggest starting over with a fresh install. If after that it's still not working, I'm going to come up with some more things to try and hopefully we can determine what's up. Thanks, Ryan

This module bolts on top of the built-in access system rather than replacing it. It gets involved in runtime access control, but not low-level access control. As a result: For the same reason, the pages can appear in your PageList, like you mentioned. Perhaps we can make a future version of this module hook into PageList and other things to add a viewable() check before showing in the PageList. But for the moment, I think this particular module is more of a good starting point for further coding/customization rather than something to use as your primary access control solution. I actually think the built-in access system with templates is the best way to go most of the time, but this module is a good fit for more rare specific instances.

I think that repeatable fields (something that is planned) will be helpful with the need you are describing. Having field labels customizable per-template is also part of the plan. Having the same field be reusable on the same template is not possible, and I'm not sure how we'd do that architecturally and technically. But I don't think that will even be a need once we have repeatable fields. A field 'duplicate' option will definitely be added.

I want to keep the default site profile really, really simple. But also want to get some more site profiles together that the user can select from, and one of these other profiles should definitely demonstrate this feature. One of these days I also want to figure out how to make the fieldsets/tabs indent on that asmSelect list in the template editor, as I think it looks a bit technical now.

Versioning of templates or fields isn't currently planned, though page versioning will probably be enabled on a template (and possibly field basis). But that would be versioning page data, not template or field settings. Though if you want versioned template files, something like Git is always a good option too.

Formmailer this looks great, and incredibly useful! This is definitely one of those things that clients ask for and I have a feeling your module is going to get a lot of use. I agree with Antti that a great upgrade would be to have a little finer control (maybe down to the hour?) whether in this version or some future version. Another nice upgrade would be having your module install/uninstall the publish_from and publish_until fields automatically. I'll be happy to show you how to do this if you'd like? --- Edit: also wanted to add: you might want to just call the module 'SchedulePosts' rather than ProcessSchedulePosts. That's because 'Process' is meant to refer to modules that extend the 'Process' module type (i.e. interactive admin modules). Also, 'Posts' is not a term that's used in ProcessWire... nothing wrong with using it, but maybe 'Pages' or something would be better? Like 'SchedulePages' or something like that

I totally agree. I've always just used the code itself as my API reference, and it is SO much easier to just keep a window open to the cheatsheet.

Thanks for posting sklwrm, but unfortunately it doesn't look like that's it. Everything looks fine there. If you click on 'edit' for one of the language files, do you see the translations there, or are they all blank? If you click the 'profile' button at the bottom, does it show Spanish as the currently selected language?

With your Process module, does it have "'autoload' => true" in the getModuleInfo() function? If so, that could be the problem. I'm guessing that's it? Process modules are designed to load on demand (when requested by a page's 'process' field) rather than automatically, so it's feasible that an autoload Process module could load before JqueryCore. The best bet is not to make autoload Process modules, and instead split off any needed autoload functionality into a sister module. The main function of Process modules is to provide interactivity for some admin function, so you don't want all that interactivity code loading on requests where it's not going to be used. A good example is the new LanguageSupport module in the PW 2.2 dev branch. The main module is an autoload module called LanguageSupport.module. But the interactive functions are split off into two other Process modules: ProcessLanguage.module and ProcessLanguageTranslator.module.

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