adrian

The last commit was Oct 9 last year and that was just a bugfix by me. https://github.com/adamkiss/InputfieldAceEditor/commits/master There is a bug in the modules directory that causes it to incorrectly report the last updated date!

Sorry, I haven't had a need for it yet, but i do think it is an important improvement for PW and I know I'll want to sort something out for a long term project I am working on, but it might not be for a couple of months still.

I think that is the only extra one that is built in, but not installed by default. https://processwire.com/talk/topic/3719-other-permissions-like-page-publish/?p=36446 One thing to note about it is that once it is installed, users won't be able to edit an existing published pages unless they also have page-publish permission. https://processwire.com/talk/topic/4094-publishunpublish-a-page-setting-required-to-edit-published-pages/

Sorry, haven't read this thoroughly, but quick comment. To pass $useMain via render, you need to use the $options array: https://processwire.com/talk/topic/3145-multiple-views-for-templates/?p=32876

I don't think it is actually added though - if you look at the field_roles database table and look for entry with a pages_id that matches the user, there won't be one. There should be one with a data: 37 (page id of the guest role). When you view the user page, there is some logic that ensures the guest role checkbox is checked, but it's not being stored in the database.

What about: foreach(array('guest', 'customer') as $r) $u->addRole($r); Still, I don't see any reason to add the guest role manually, so if you are only adding one other additional role, then you probably don't need anything to reduce multiple lines. It seems like maybe something changed recently. What version of PW are you running? If I test on 2.4.5 the guest role is automatically added, but not in 2.4.11 - https://github.com/ryancramerdesign/ProcessWire/issues/588 Wow - I am having a rough morning - nothing has changed - behavior seems to be consistent through versions.

Try mousing over the collapse down arrow over on the right - that does what you are looking for, or better yet, install: http://modules.processwire.com/modules/helper-field-links/

Are you still trying to call $page->blog_summary; etc? If you are on the homepage, you need to define the page of the post that you want to get the content from. Perhaps this does what you need? $lastPost = $page->children->last(); echo $lastPost->blog_summary;

I don't think I am missing anything here. Isn't it as simple as echo'ing $t->id ? You have t->id

The table name should be: ProcessRedirects - so you should be able to just rename it using PHPMyAdmin or via SQL command line. It is created here: https://github.com/apeisa/ProcessRedirects/blob/master/ProcessRedirects.module#L326 Did you move from Windows to Linux? Names are not case sensitive on Windows, but they are on Linux? Still, not sure why it would have been created in lowercase in the first place, given the code that creates the table.

https://github.com/NicoKnoll/InputfieldQuickTags

Saving a site profile like Nico mentioned is a great option if you want exactly the same starting point for each site. If you want some more flexibility, there are a couple of other options. One is the new field migration tools built into the dev version of PW. There are template migration tools coming shortly. See here: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/page-6#entry68899 The other possibility is Migrator (https://github.com/adrianbj/ProcessMigrator), which can migrate a page tree and its fields and templates (and template files). With this option you can install the default PW profile and then add in additional components as required. If you think the components are generic enough that others might find them useful, you can even contribute them to https://github.com/adrianbj/ProcessWirePageLists/ and they will be available as an automatic install directly from Migrator.

Just a head's up - as of today, the dev version of PW now supports CURL if allow_url_fopen is disabled (https://github.com/ryancramerdesign/ProcessWire/commit/bbd7569de8f9b398d35e2a12226a4e34b1224bf8) so if your host supports that by default, you may not need to do any modifications to get modules downloading automatically.

Yep - I did click on the module title I do think that javascript action should be removed - it confused me

Maybe this could be a new third party plugin for the Migrator module (https://github.com/adrianbj/ProcessMigrator) If you haven't seen it already, the first plugin for it is Nico's MigratorWordpress (https://github.com/NicoKnoll/MigratorWordpress) which also converts XML to JSON for use with Migrator. I'd be happy to help if you have any questions on how to implement.

This is what soma is talking about: https://processwire.com/talk/topic/6605-module-textarea-preview/

There is also this plugin for CKEditor: http://ckeditor.com/addon/mathjax As of yesterday's PW dev version, external CKEditor plugins are supported and very easy to manage: https://github.com/ryancramerdesign/ProcessWire/commit/4b12d2e4f2ceb7eebb52261e723a847e08c8a569

There is a threaded comments modification available for PW: https://processwire.com/talk/topic/2623-comments-core-reply-feature/ I haven't tried this with either of the blog options, but I would imagine it will work.

You need to set outputformatting off before you save: https://processwire.com/talk/topic/490-how-to-reset-your-password-how-to-enable-the-forgot-password-function/

You can use markdown. Does this help: https://processwire.com/talk/topic/1424-html-in-fileimage-descriptions/

I am surprised you were able to install ProcessLanguage before LanguageSupport since it is listed as a requirement. ProcessLanguage is normally installed automatically. I did just test installing ProcessLanguage on 2.4.10 and weirdly it doesn't tell me it can't install, but then it doesn't actually do anything either - the confirmation alert pops up, but then nothing happens. I'll make sure Ryan knows about this, but for the moment, your best way to get things going again might be to remove the language modules from the PW modules database table, and potentially also the relevant rows from the pages table - look for anything language related there. Maybe even drop the entire field_language and field_language_files tables. Are you comfortable with PHPMyAdmin or similar for managing DB tables? I am certainly no multi-language expert, so you might get a better solution from someone else. If you do take this approach and the site contains any important data, please do a complete backup first.

Hi moonwhaler, According to teppo's first post:

I think that sounds reasonable and doable, but of course cookies can be cleared and computers can be shared by multiple users, or a user may have multiple computers, so it can only be useful to a certain level of certainty if you are trying to find users who visited a page once as a guest and again when logged in. I guess it really comes down to the exact info the client wants to determine.

http://cheatsheet.processwire.com/page/built-in-methods-reference/page-of-true-false/ http://cheatsheet.processwire.com/page/built-in-methods-reference/page-setoutputformatting-true-false/ Those should answer your question better than I can Just had another thought on that solution that you might want to consider. You may want to check to see if there is already an entry for the current user and current page (maybe for the given day, or maybe ever) and not add an entry if it already exists. Of course this depends on your needs, but no point populating the table with unnecessary rows.

muzzer, Your scenario is exactly what Migrator was designed to do. It does not migrate page IDs at all. Every reference to an id gets converted to a name/path on export and a new page id created on import to the new site. I would still recommend testing the migration to a test PW install first until you have a full understanding of all the import settings and how they can affect the import. Also when you do it to the live site, please make sure to backup your database first. This module generally works as advertised, but there are some weird scenarios like what Macrura experienced with a page field that points to users that can cause problems. I will be fixing this shortly - I just need some more info from him. Please let me know how it goes for you and if you think of any possible improvements in the way it works.