Leaderboard

------------------------------------------------------------------- LanguageFieldTabs is now included in ProcessWire by default (version 2.4). Unless you are using version 2.3 DO NOT install this module, instead navigate to Modules and then core and you will find the module in the Language section ------------------------------------------------------------------- LanguageFieldTabs Beautify and organize you Field Languages into tabs! DOWNLOAD - Github DEFAULT UI UI IN "UNIFY" ADMIN THEME Sorry for the lack luster write up, will add to Modules Directory later, late, long day tomorrow. Enjoy! (very much beta maybe alpha, minimal testing, just quick evening idea at this point). Changelog v1.0.2 Improved styling capabilities (added surrounding class "LangTabsContainer" ) Added admin wide support Fixed description text order (was being pushed to bottom) v1.0.3 Added support for toggling tabs display and faded labels to represent empty fieldsv1.0.4 Fixed tabs destroy error Moved toggle into Inputfield ui-widget-header

A little something I've been working on for a while now. I decided I wanted to created a theme that felt like a natural fit for ProcessWire; light, clean, efficient and straight forward. So I took to using what I had learned from the themes I had created in the past, took some vigorous inspiration from the new website and got to work. And this is what I've created... so far of course Unify Admin Theme DOWNLOAD ***** Updated for compatibility with current dev 2.3.5. ***** Login Page --------------------------------- PageList ---------------------------------------- PageEdit ------------------------------------- Image Insert Dialog ----------------------------- Subnav Dropdown ------------------------------------ Features subnav dropdown menu gravatar user profile images CollagePlus image insert layout customized CKeditor theme (minor tweaks, but it really fits in nicer) Enjoy! I will continue to tweak and perfect this theme so be sure to let me know if you have any issues or suggestions. I would consider this a beta for now as I've done little to no cross browser testing. Thanks!

Textformatter for Google Maps https://github.com/teppokoivula/TextformatterGoogleMaps This module looks for Google Maps URLs (such as https://maps.google.fi/maps?safe=off&ie=UTF-8&q=disneyland,+paris) within paragraph (<p></p>) HTML tags and automatically converts them to embedded maps. Configurable options include embed type ("static" or "iframe"), API key, responsive embedding and Google Maps for Business settings. Other than that, it's pretty basic stuff. Original regexp for grabbing maps links was posted by Ryan (I believe) here on the forums, but I couldn't find that post anymore. I've altered it to better suit the needs of this module, added some configurable features (part of which, such as makeResponsive() method, are again based on Ryan's TextformatterVideoEmbed module) and so on. Hope someone finds it useful. (By the way: if you're going to use Google Maps for Business settings, please read the notes there carefully. Google doesn't exactly recommend storing your private key the way module settings are stored..)

Hey, I needed a newsletter system for two websites I'm currently building. So I wrote a standalone ProcessWire newsletter system called: MarkupNewsletter The video below shows the workflow: https://vimeo.com/68954976 (it's still converting) Hope you like it! Please report any bugs or questions here. (I'll add it to the modules section after a short beta time). / Nico

Greetings, I was just about to post about the same thing that mindplay.dk posted above. When I built my first site requiring image management, I worried about images being separated from the WYSIWYG field. I thought the client would be unhappy with it. But it turned out they actually like the idea of seeing a list of images associated with the page. This surprised me. But now I think it makes sense. Although the images are separated from the text field... 1. This helps users visualize the page better to know what's available 2. At a glance, users can get a sense of the photographic presentation of their blog post or other page 3. Users can upload all the needed images at once 4. After uploading images, it's then simple for users to include them (same process as if they had not done an upload first) 5. I find that users think "page" more often than "site assets" anyway This could be one of those cases where we assume one way is easier, until we actually let users try another way. This is just my experience. Thanks, Matthew

Okay now, let's not throw out the baby with the bath water For the time being, I had to simply use the image-field the way it was designed - in conjunction with a WYSWIYG. I keep the image field "always collapsed" in templates where this field is exclusively for use in one or more WYSIWYG fields. It still doesn't make a whole lot of sense to me, personally - but the guys who populate the CMS are quite happy with it. One guy remarked that he likes the idea of being able to expand the image field and get an "inventory" of the images that are in use on that page. I'd like a better solution eventually, but if the end-users are happy, it's probably not a big deal. This solution is acceptable to me for the time being, until I can find the time/resources to build (or help build) something more advanced...

Not sure what you mean with these .json and .zip files, but I'm guessing you're saying that they weren't there in some language pack you've downloaded? Not all language packs contain all files -- there may be more translatable phrases now than there were when the language pack was created etc. so you'll have to either translate these manually or post a heads-up about these to the maintainer of that particular language pack. Anyway, if you want to translate this file manually then just follow these steps: Log in, go to Setup > Languages and select target language At the bottom of "Language translation files" follow the "translate new file" link Type whole path (\wire\modules\Inputfield\InputfieldPage\InputfieldPage.module) in the "File to translate" input Translation page should open -- now you'll just have to translate phrases manually and save If I'm understanding something wrong here, please provide some extra information about what you're exactly trying to do.

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

@kongondo - thanks and apologies for my verbosity.. so this can be fixed by changing line 72 and 75 like so: } elseif ($this->page->child('include=hidden')->id) { // for the current stable version use this method return $this->page->child('include=hidden')->render(); and then making the child page hidden.. well you beat me to it...but your code looks slightly different

Really easy I guess because sending and creating a newsletter are separated. So you could create it and then hook into the send function and combine this with a cron job.

Really nice UI solution when working with more than 2 languages. Most often the simplest solutions are the most difficult to think of.

If $user->user_city is return a number, then surely $user->user_city->title will give you New York etc and $user->user_city->name will give you new-york. You should use name for all cases where you are storing the city and checking it against another variable. Then use title to display it. However I think you know this already. Not sure if your user's city field is a single or multiple, but you should make it single, otherwise you might need to use $user->user_city->first()->title to get the title. I haven't used the FrontendUserProfiles module (I have done a custom setup), but I wouldn't worry about modifying it to suit your needs. Perhaps rename it so there is no chance of it being overwritten from the modules manager if you do an update. Or you could convert it so it is no longer a module - take the code and use it I don't think you need the linked page for the user's data - I still think the best way is to add those additional fields to the user template - that will make accessing this info much easier - eg: $user->user_city

Hi Thomas and welcome to PW! You should be able to do this with a very basic custom module. I think this code from Pete should be a good start for you: http://processwire.com/talk/topic/1648-ok-to-change-page-name-path-after-save/?p=15232

A few things: Is there some reason you can't simply use $user->user_city instead of the following. Remember that you can add custom fields to the user template. $options = $fields->user_city->getInputfield($user)->getOptions(); $u_city = $options[$user->user_city]; I always liked to use selected="selected" as this is XHTML compliant, but it seems that maybe just selected is now valid HTML5 The value of the option tag is whatever you set it to. If you set it to $city->name, then you want to use $city->name in the "selected" statement. Take a look at the source of the form on the rendered page to see what the value of the options is showing and echo the $session->current_city and see if they match. That should help you debug.

This one really did it. Amazing aha eye opener for evo people (like me). http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/#entry35953

Sorry, my fault: foreach($page->children('theatre_city='.$session->current_city) as $child){ or foreach($page->children("theatre_city={$session->current_city}") as $child){ On another note, you might want to modify this line in your select creation to the following: echo '<option value="'.$city->name.'"' . $session->current_city == $city->name ? ' selected="selected"' : '' .'>'.$city->title.'</option> This will ensure that the select dropdown highlights the current selected city.

It's just a 404 message. I'm with that the editor doesn't need to edit that text. That's why it's set in the core (page id) to be only listed in the page tree for superusers. The 404 is just a regular page that is defined in the config via page id. You can overwrite that with $config->http404PageID = 1024; But this will just that page also. SOmething like kongondo would be a solution to still make it. You could add a settings page or even better a custom 404 page with the same template as the 404 page and have it in the tree set hidden. To replace the rendered page of the 404 page with your own created page, you can add a hook with a autoload module. Look at HelloWorld.module which is such a module that autoloads on each request. ... public function init() { $this->addHookAfter("ProcessPageView::pageNotFound", $this, "hook404Page"); } public function hook404Page($event){ header("HTTP/1.1 404 Page Not Found"); $page = wire("pages")->get("/404/"); // get your 404 page $this->wire('page', $page); $event->return = $page->render(); // render and return that page }

I haven't used those modules before, I'm afraid. You would want to post any issues about them in their respective support threads... By the way, a different approach to the above: You can also create a "settings" page where you can throw in several fields to hold various pieces of information about the site that your client can easily edit in one place. This only makes sense if you have several settings you want to allow him to edit. E.g., a site slogan, a 404, message etc. If you take this route, you can have a text area field on that page, called, for instance, "404_message" which your client can edit. On the template file of the 404 page itself, you would reference the "404_message" field in the "settings" page as follows: echo $pages->get(123)->404_message;//where 123 is the ID of the settings page. You can also use the path Like I said, this only makes sense if you have several settings. Additionally, you can even make it more full-proof. E.g. $message = $pages->get(123)->404_message; if ($message) { echo $message; } else {//echo your normal 404 message in case client forgot to fill his custom 404 message in the settings page } Quickly written, not tested Edit: Yeah; you'd want the "settings" page hidden in case you went this route...

Greetings, Yes, unfortunately, Gretag is gone. I lived througn its demise. They were a good example of what happens when a company refuses to change with the times. They made film-developing machines. When it was clear that film was finished Gretag stuck with it. I remember at one of our final company meetings one of the executives saying that they will not transition to digital because film is better and people will always want what's better. But Gretag is where I made my first "web sites." In 1999, I began building a distributed online help system for their machines. That's when I started using "Macromedia" Fireworks! That was my best non-independent jobs ever. And I really enjoyed traveling to Switzerland. I remember being impressed by how orderly everyone was, that dogs were allowed in restaurants, and the fact that all the clocks in the subways were synchronized. Thanks, Matthew

Will he be regularly changing the 404 message? If yes, why? Why don't you get the message from him and change it yourself when setting up the site? If he must do it himself, there is a module Page Edit role or something. Have a look at the modules site Edit: Here they are: http://mods.pw/34 http://mods.pw/4X http://mods.pw/39

Kongondo, you should get some kind of forum member award. What you are posting lately is really amazing and helpful for pw users with little coding expierence. Thanks !

I really prefer to keep images in their own fields, separate from a textarea/TinyMCE field. It's not about any limitations at all. I've just found this to be the most flexible way of managing this over a long period of time. ProcessWire has always been built to what was ultimately most flexible rather than trying to do the same thing as other CMSs. But I do recognize that it's controversial and may seem unfamiliar if one is already used to a different way. I'm not against alternative patterns for this if it helps appeal to more coming from other CMSs, though not at the expense of the current one which I think is the ideal (at least for my needs). So I always try and keep an open mind about it and am open to supporting more options for those that want them in the future.

This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose. Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred. Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting. Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that? (Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.) Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference. Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?) Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself

For the most part, I like the way that it works now. It's not really a "technical limitation," but a matter of flexibility. No matter how you do it, it's going to be a 2-step process of uploading and selecting the image, but the PW way bypasses having to build a separate folder structure while uploading your images and then having to hunt them down afterwards, while still retaining the flexibility of using images that appear on other pages if you want to. When you "add an image to the page" you literally are doing just that--adding an image to the page. Keeping the images separate from the individual WYSIWYG fields also allows you to reuse images more easily (in other WYSIWYGs or in your templates) and to see at a glance what images you have stored & available for use on that page. I think that it is actually more intuitive for people who are not familiar with CMSs at all. Plus the drag-and-drop functionality and auto-resize settings in the image containers bring a whole new level of usability to the CMS. I do agree that being able to drag and drop from the images field to the WYSIWYG would be an excellent feature, though. All of that being said, I recommend using individual custom image fields and outputting/resizing those images directly in the template with the API as much as possible. I have found that it is the most foolproof system for clients, and is where ProcessWire truly excels. Only use images inside the WYSIWYG for inline article images and never for images that are part of the site's layout.

In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way. Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.) Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really. Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs. Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable

I just pushed an update to 0.0.2 to github. Some refactoring and some changes - changed image tag syntax to use selector string syntax. This is easier to handle and I can use the PW selector class to read key=value easily. Now supports: {image=/path/, width=200, height=200, class=someclass, id=myimage, rel=album} - improved image upload to use the image field settings for max size settings, also improved error handling there- added some translations string - changed data table some and added a input for the tag where when you click it will select the tag text automatic for easy copying. - added modified date (sortable), also fixed some stuff with sortable of other cols - added size col - improved data table live search to search for also image description or image description field and title Planned - improve upload even more if/where possible - add easy image delete function - (Done) add textarea fields setting, to only insert "ImageManager" button to those specified Any testing or help appreciated. Thanks

Yep, works great! In case anyone is following along, my original example is updated and working correctly. Thanks Ryan!