ryan

Here's how to create a new field from your install function: <?php public function ___install() { $field = new Field(); $field->type = $this->modules->get("FieldtypeDatetime"); $field->name = 'publish_from'; $field->label = 'Publish From Date'; $field->dateOutputFormat = wire('config')->dateFormat; $field->dateInputFormat = wire('config')->dateFormat; $field->datepicker = 1; // if you want datepicker enabled $field->defaultToday = 1; // if you want dates to default to today $field->save(); // repeat for publish_until field } public function ___uninstall() { // only do the following if you want to uninstall the fields that were installed // this may be one thing that's safe to leave to the user $field = wire('fields')->get('publish_from'); if($field && $field->numFieldgroups() > 0) throw new WireException("Can't uninstall because field publish_from is still being used. Please remove it from any templates."); wire('fields')->delete($field); // repeat for publish_until field } Creating tabs is a little different because not only will you have to create the field, but you'll have to add it to fieldgroups. And I'm not sure how you determine what fieldgroups it should be added to. I think this is almost something that is better to leave to the user... or handle on the module's config settings, where they can check boxes next to the templates they want to have scheduled pages. If you are interested, I can help with that next week – my wife gives me crap about being on the computer on the weekend.

Great idea Nico, thanks for getting the ball rolling on this! I've been thinking more and more about this modules directory, and it looks like we're both on the same wavelength here. I think your spreadsheet gets it nearly perfect, just a few tweaks I might suggest – let me know what you think? 1. Ultimately I want people to be able to browse by module type. So I'd suggest adding a column for module "Type" and optional "Subtype". Types would be: Process, Text formatter, Input field, Field type, jQuery, Markup, Page, Language, and Other. If it falls under "other" then, they would specify their own Subtype. I'm not positive this is the best categorization, but it's the only one we've got so far. If anyone has any ideas for a better categorization, feel free to suggest things, as the module directory may benefit from a different categorization system. 2. Instead of just Download URL, I'd suggest these 3: GitHub URL (you already have this, but we'd require a GitHub URL) Direct download (ZIP file) URL, regardless of where it's hosted (GitHub or otherwise). Eventually I want people to be able to install modules directly from the PW admin, so having a direct download URL will facilitate that. Forum/Support URL (you already have this, but we'd keep the URLs columns all together) 3. In addition to 'description', have an optional extended description. Perhaps the two could be called 'summary' and 'body' or whatever you think is best. I'm not suggesting this to replace the "how to install" that you already have–keep it, it's great. I'm just wanting for people to have the option of including an extended description for the module's landing page. Whereas, the short 'description' or summary would appear in the module listings. 4. I like what you've done with having the creator name and forum name. Just wondering if we could split them in two columns: creator full name, and creator forum name (if multiple, then they would be split by commas). Ultimately I want people to be able to add and manage their own listings, and PW's going to need easy access to their forum name for authentication. We could get it in the parenthesis like you have, but thinking it might be even better just as separate columns… but you decide.

Christoph, that plugin formmailer referred to is the way to go for now, but I do plan to make it built-in in the near future.

I actually didn't understand it myself until I ran across the same word needing to be repeated in multiple places in the search module: 1. The "Search" placeholder text in the input[text] at the top right corner 2. The "Search" headline at the top of the page 3. The "Search" submit button in the sidebar search So it's the same word repeated 3 times in the same file (meaning, in the same textdomain). All is well and good in English because it's the same word and who cares if it's repeated. But when it comes to other languages, text used in a headline, text used as a placeholder in an input, and text used in a button may need different translations. So this "disambiguation by context" means we can use the same word repeatedly and not have them all use the same translation. So here's what's happening in ProcessPageSearch: $this->_x("Search", "headline"); $this->_x("Search", "input"); $this->_x("Search', "submit"); If some language needs those 3 to result in different translations, they can, thanks to disambiguation by context. It's a small detail, kind of like plurals, but I think its good to get the details right, even if they don't come up very often.

Nice work Antti! I'm amazed how quickly you got this done, you guys are all amazingly fast with this stuff. I must admit, Finnish is one cool looking language. I love the translation for "Access" – it's just nice to look at ;D Käyttäjähallinta That seems like a good idea. This one is possible, but a little more tricky than other parts of PW. This is because none of this data is in the database, it's all in JSON files on disk. Kind of like with gettext how all its data is in those .pot files or whatever they are called. Though in our case, JSON files are just text, so solutions are within reach whether based on grep or just loading the whole file and matching a string with stripos. If this is a recurring need we'll find a good way to implement it.

Great! Glad that was it, thanks for testing it.

Nice work Nikola! What script are you using for the dropdown menus?

I think that was it, the "\" vs "/" on windows vs. unix. Can't believe I didn't think about that before. I just committed an update that accounts for that, and am hoping this might fix it. Please let me know. Thanks, Ryan

Thanks for testing. It's probably something stupid on my part like forgetting to account for the differences in Win vs. unix slashes. I'll do more research here and track down what the issue is and post an update. Until then, I also wanted to show you how easy it is to use the translation functions in your own site templates. Here is a short video that demonstrates how to do it: http://processwire.com/videos/processwire-language-translation-example/

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.