Leaderboard

Sorry I'm a little behind with messages here, I'll be caught up by mid week. But I've got a good excuse. Yesterday Karena Savannah Cramer was born. She is our 2nd daughter (Hanna Ryan, age 3 is our first). We will all be coming home from the hospital hopefully tomorrow.

Hello Everyone - I am pretty new here - came across this CMS based on a friend of mine who has indicated she used this CMS and loves it. So when she says she loves it then I take her word for it - you might know her as Eisteinboi or Mary. I have been a long time MODX user (and I see there has been other MODX users who have jumped over here as well - so that helps me) Did an install of ProcessWire for one of my Personal Projects I am doing here for the Deaf Community here in Houston. So I am looking forward to my Processwire Journey. So now just need to jump in and figure out how everything works. I'm excited about this Processwire journey, and hopefully if I like it - then maybe more projects to build with it. Thanks for making an awesome product! Have a great one! Billy Koch

Diogo, Can't wait to test this tomorrow morning. If it does what I think it does, I'll be on the first plane to Portugal to buy you all the beer you can drink.

I made some corrections in the original post... hope this doesn't get too confusing. Maybe I will rewrite the whole thing when I have learned a little more.

Create custom admin pages easily without having to build a Process Module especially for that. ☞ This module makes it easy to create simple admin pages but you can also create them in much more powerfull way without the need of a module. Have a look at this post written by Bernhard Baumrock to know how it's done https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ ------- I just updated the module, I kind of merged the two versions and now it works with both stable and dev versions of PW. Only difference is that with the stable version you still need to create the child pages and with dev version that is not needed. The instructions are on Github. Enjoy ---- Download or clone from Github https://github.com/ocorreiododiogo/pw-admin-custom-pages Module page is here http://modules.processwire.com/modules/process-admin-custom-pages/

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

ditto, beers are owed. this is such a great idea and comes in and solves something that i was planning on doing with a module, once i got my head around that, which could have been a while from now.

You could also do this: if ($page->is("name=slideshow18|slideshow28|slideshow38") { I prefer this method, since it's slightly shorter, bit more readable and doesn't need to fetch any additional pages just for comparison.

Hi all, I just switched to processwire from MODx and I am really impressed of how clean, fast and intuitive this system is. My first project with processwire happens to be a multi language site, and I am really happy that it can be done with a single page tree. However, I had to dig the forums a lot to find all information i needed to get everything working, so I thought I share my newly gained knowledge... The order of the steps is important, especially if you are working on IIS (which can inflict database damage if you add languages before you change the field types!) 1. Install the Language support modules: - Languages Support - Languages Support - Fields - Languages Support - Page Names 2. Change any existing Fields of types Textfield/Textarea/PageTitle to TextLanguage/TextareaLanguage/PageTitleLanguage You now will have an input field for each language you add. 3. Set up your languages under Setup->Languages (define a name and title for each language. For each new language, you will have to add a title to all the other languages in that new language) 4. Edit your homepage, set it to hidden and unpublished. UPDATE: don't set the homepage to unpublished, the first-child-redirect won't work! (I realized just now, because if you are logged in as admin, it does work) For each language, you have to define a unique name (e.g. "de" and "en") 5. Edit your "home" template to redirect to its first child: <?php $session->redirect($page->children->first()->url); UPDATE: this is not essential... as ryan pointed out, it might even be better not to do it (for SEO-optimization) 6. If you have something like $children->prepend($homepage); in the menu part of your head.inc, remove it (you don't want the home page to show up in your menu) UPDATE: if you left out the redirect option, you'll want to leave this out as well. 7. To switch languages, add this snippet to your head.inc: <ul> <?php $user_lang = $user->language; foreach($languages as $language) { $user->language = $language; if($language->name != $user_lang->name) { echo '<li><a href="'.$page->url.'">'.$language->title.'</a></li> '; } } $user->language = $user_lang; ?> </ul> Each language except the currently active one will be displayed in a list (of course, this can also be done with a select field). UPDATE: Ryan pointed me to a better solution for the langugae switch: http://processwire.c...s-urls/?p=33537 8. Done. Now your page urls should look something like path/to/root/en/my-page, or path/to/root/de/meine-seite It took me less than a day to set up processwire, install my html template and configure the site to be multi-language... this is so great, considering the pain multilanguage sites usually cause with all the other CMSs... Keep it up! UPDATE: I was a bit quick to post a tutorial just after one day working with PW... should have made some more research beforehand. Just got a little too excited there... I'm still impressed by the system and plan on digging deeper into it.

You could use hashs //set window.location.hash = someid; // get hash = window.location.hash; and use $(window).on("hashchange", function(e){ var hash = window.location.hash; // do what you need }); BBQ might a little overkill for your needs, but you could use the simple hashchange implementation plugin of it.

I think it's great that you wrote the tutorial. It shows how easy it is to create a multilanguage site with PW. Maybe you could update the original post with Ryan's suggestions.

I think first one is cleaner, but both of those will fail, if you change your page's parent. You could try this also: $pages->get(1234)->url where 1234 is page id.

CONGRATULATIONS!!! From one father to another... You have some important matters to attend to right now, so don't worry too much about the forum! Let us know how we can help. Again, congratulations! Matthew

I didn't know this, but in CKEditor you can also paste the image. Just tried it, and worked

I wonder why this is the case? Sounds like bug to me, I will have to try and duplicate. Has anyone else run into this? I'm unclear about why the homepage should be hidden and unpublished? From an SEO standpoint, I think it's a little better to let your homepage (root, no language segment) serve as the homepage for your default language. The thinking here is that people often link to your domain rather than a specific page in the domain. It's technically stronger to have those links resolve to an actual page rather than to a redirect. Here's another good example of a language switcher that uses the multi-language page names module: http://processwire.com/talk/topic/2979-multi-language-page-names-urls/?p=33537

Maybe like this? $ts = $page->getUnformatted("datefield");

can you replace the entire tinymce module folder for a new one? Just for the case that something was not copied.

look in /site/modules/ you will. missing.a. feldtype or.inputfeld module u are

( ohne Worte - without words )

Hi all, My first post. I’m Kongondo. I am coming in from MODX hence “recognise” a few faces here. After many, many months of contemplation and searching for a MODX replacement, I came across ProcessWire for the second time. First time I heard about ProcessWire was maybe a year or so ago. Back then, I checked it out but quickly moved on since it seemed like a “one-man-project”. I was also thrown off by the simple interface; I judged a book by its cover and thought no way this CMS is powerful…so I moved on. My search for a CMS continued....About a month and a half ago, I came across this post by Mademyday so I checked out ProcessWire once again, this time digging deeper into its guts and boy was I impressed! For the last one month I have read every Forum post, bookmarked key threads, watched the videos, dug into the demo site, Googled, etc. and installed and played with ProcessWire locally. Honestly, I have been blown away! Finding a replacement for MODX was tough; but now, I have found it. Ryan, congratulations; this is an amazing framework you’ve created and thanks for releasing it as open source. I am a “tutorials-kinda-guy” so I am already working on ProcessWire lessons which I hope to post on my website soon. I know there’s the Wiki work going on but I think the more lessons we have out there the better for ProcessWire. Then again, I’m not a fan of Wiki markup . Cheers /k

Dear Ryan, My four children can't even relate to the concept of a "BBS". "BB What? Does that come on the new Galaxy phone? Huh?" But just wait. Their children will say, "What do you mean, 'cell-phone?' You mean you don't have a wall in your house that turns into a 3-D viewscreen for phone calls, that makes it look like the other person is sitting in the room with you? How quaint." Peter Dear Ryan, Oh; and thanks for the stats about the millions of pages. I'm *very* encouraged about PW! Peter