Leaderboard

ProcessWire2.+ Admin Hot Keys 0.0.7 This modules adds hot keys functionality to PW backend. The keys can be configured in the module settings in the admin. I created a repo here for download and if anyone interested in picking it up. https://github.com/s...ic/AdminHotKeys Currently it supports Save : ctrl+s Add New : ctrl+n View Page : ctrl+v Open Pages search : alt+q (search field can be configured) Open Templates search : ctrl+shift+t Open Fields search : ctrl+shift+f Goto Pages : ctrl+shift+p Goto Setup : ctrl+shift+s Goto Modules : ctrl+shift+m Goto Access : ctrl+shift+a Note: If you're inside a text input it will ignore the hot keys, as to avoid problems with already defined key. Tip: If you open up templates or fields autocomplete search `ctrl+shift+f|t` press `shift+tab` to focus on the link in the label previous to the search input box. Now hit enter to get right to the template or field screen. (If using FF make sure to enable tab focus for all elements in MacOSX: http://support.mozil...enus or buttons)

It’s not that easy. The display quality of a font file, using ClearType technology, depends on what’s in the font file. E.g. the OTF font format is only a container. The “real” font file inside the OTF container can be either PostScript or TrueType. If a PostScript File is inside, chances are good that it looks smooth in big font sizes. That’s because Windows falls back to standard (which means grayscale) font smooting instead of ClearType for PostScript fonts. Grayscale smoothing is not crips enough for small font sizes, but usually looks good for big sizes. So wether a webfont looks good on a windows machine depends on the type of font file combined with the used font size and font smoothing technology.

Ok, I have implemented a language domains option you can now enable in the module settings. I did some testing on my local install and so far everything works as it should. I just commited the update and it's ready to use. urlSegments , pager, page links in language text fields still work and I didn't notice any problems. However it's not sure any other side-effects pop up I may missed, apart from the ones already there. From readme: This module now supports language domains. So you can have each language mapped to its own domain. To make this work you need to have the different domains point to the default domain and PW install. Then enable this option in the module settings and enter your domains in the textarea, each domain on its own line. The format is [domain:langcode] i.e.: domain.com:en domain.de:de domain.fr:fr You could also use subdomains: en.domain.com:en de.domain.com:de fr.domain.com:fr Result: Now you can access the different languages simply through the different domains. For example the "/about/" page would be available like this: domain.com/about/ domain.de/ueber/ domain.fr/au-sujet-de/

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

I tried to integrate parts of another site with ProcessWire today, and quickly gave up, as my existing (older) site has a bunch of classes in the global namespace that collide with some very generic class-names in ProcessWire: Database, Config, Session, Page and so forth. Would you consider introducing support for namespaces? Perhaps in ProcessWire 3.0, as clearly this would break backwards compatibility with the current API. Simply placing PW classes in a vendor-namespace (e.g. "wire") would probably be sufficient to avoid 99% of collisions. I think it would be great if PW-modules followed the "{vendor}\{package}" namespace convention for modules, as this eliminates practically all namespace collisions. Both conventions are compliant with the PSR-1 recommendation - though vendor-name is the minimum required, but I think that's fine for the framework itself. A "smart" IDE like PHP Storm could probably refactor most of the codebase to use namespace more or less automatically. If you're interested, I also have a script somewhere that rewrites entire codebases to namespaces, picks up folder-names and maps those to namespaces as configured. (it's not complete, but would probably get you roughly 971/4% of the way...)

After reading the PW documentation I decided to utilize a small client project as a CMS test case. Fortunately everything went well I only needed 40 minutes to show my colleague who did the content editing part, how the CMS works. I never did such a short CMS training, even if I always customize every CMS backend I use in such a way to make it as DAU-proof as possible ;-) So here it is – just a nice little website which makes quite heavy use of PW’s image and thumbnail handling (e.g. for all the different logo and image sizes): www.campusroethelheimpark-erlangen.de

Basically bind a shortcut to the save button in processwire

I just started and created a simple module to add hot keys, currently only starting with Page Save. https://github.com/somatonic/AdminHotKeys

I just added it to a german site. Maybe you want to incorporate a german translation. ProcessWire im Fuß anzeigen? Wenn deaktiviert, wird der kleine "Powered by ProcessWire"-Slogan nicht in der Fußzeile erscheinen. ProcessWire ist Open Source und freie Software. Dieses Kontrollkästchen aktiviert zu lassen, ist eine Möglichkeit, Ihre Wertschätzung und Unterstützung zu zeigen. Das ProcessWire-Entwicklungs-Team bittet darum, soweit möglich, im Austausch für die Verwendung der Software. Allerdings ist es Ihre Entscheidung und kein Muss. BTW: I also learned something: How to set an option only once for the home page is valid for the whole site.

Hi Soma, it does not work - It says "File API & FileReader API not supported". I think my question is answered then... Too bad though. I'll just use chrome then Thanks guys! EDIT Thanks Martijn

Don't know why but the php mail function doesn't seem to work on OSX Lion ( on my computer ). Configure Postfix for Gmail SMTP did solve it. Maybe this will be handy for someone who has the same problem.

Just a quick heads up about a gotcha that had me going for a few minutes this morning (and a note to Ryan). One of my sites was getting battered with comment spam this morning, so I searched the forum for Ryan's description of spam proofing the comments module, so I used the search and found the thread and copied the code and it didn't work, at least the javascript that Robert Zelnick posted didn't seem to. It turns out that the highlighting of search results seems to have munged the code - Whereas it should look like this - Note that one instance of #CommentForm has been un-PascalCased to #Commentform and Robert's code was perfectly good. (I have said before that I didn't care for search term highlighting and now it looks like I have a got a good reason other than personal preference. )

The only way I could see to do this is create a template that has a Title and Page field - then create a hidden YourMenuName field under a hidden Tools page (or whatever) and start building your menu using this template. It's simply a case then of building your structure using this template, entering the titles and linking them to pages in the site. Rinse as repeat for as many menus as you like. That in fact is pretty much the only way you could build entirely different multi-level menus to your main site structure, and it's also really simple. I might have to like my own post

It's working (sgym.de / sgym.eu). Thank you!!!

This should be included in default installation

I've actually got a lot of updates coming for the PageLinkAbstractor module that I was working on in the last couple weeks. Beyond what it was doing before, it now also keeps track of links to deleted pages and deleted images or files. When it detects a broken link, it logs it and optionally emails you about it. It also keeps an alert at the top of the admin screen telling you about it with a link where you can go review it. Once you fix the broken links, it detects they've been fixed and clears the log of fixed errors. Here's a couple of scenarios that it covers: 1. Page /about/ links to /products/widget/ in the bodycopy (TinyMCE) field. The /products/widget/ page gets moved to the trash or deleted. Since /products/widget/ is gone (or at least, not accessible to anyone) the link is broken. 2. Page /about/ has a photo embedded in the bodycopy (TinyMCE) from the /events/bbq-fest/ page. That photo gets deleted from the /events/bbq-fest/ page, which causes a broken image to appear on the /about/ page. Both of those errors would be automatically detected, logged, and emailed to you, so that you can fix them. It's keeping track of this stuff so that internal broken links don't ever get to persist. With these additions, the module is also being renamed to LinkMonitor, LinkNotifier or LinkPolice (still deciding), as I think PageLinkAbstractor is just a bit too technical sounding.

There's no field access yet, but I've heard rumors that it will come sooner or later. However you can create a simple module that does hide/show fields on a condition, whether a custom permission, role or user. Following is a simple autoload module that hooks the Inputfields and returns empty string, if condition aren't met. Actually very straight forward and powerful. There could be added some module configuration, to simply add fields via a textfield you want to hide for other users. Possibilities are endless. Save the code as FieldHelper.module and put it in /site/modules/ Configure it to your needs and install it. <?php class FieldHelper extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'FieldHelper', 'version' => 100, 'summary' => 'Hide fields depending on permission, role, or user.', 'singular' => true, 'autoload' => true ); } public function init() { // add after-hook to the inputfield render method $this->addHookAfter("Inputfield::render", $this, "renderField"); } /** * Hide fields depending on permission or possibly role, user * */ public function renderField(HookEvent $event) { // get the current field $field = $event->object; // example 1permission if($field->name == "pre_content") { if(!$this->user->hasPermission("admin-fields")){ $event->return = ''; } } // example 2 role if($field->name == "after_content") { if(!$this->user->hasRole('superuser')){ $event->return = ''; } } // example 3 user if($field->name == "page_scripts") { if(!$this->user->name('admin')){ $event->return = ''; } } } } I created a gist for this example here: https://gist.github.com/3122191

Hi, Michal. I'm not sure you need to delete "core" permissions for they provide Processwire's essential functionality and, btw, you can't delete them from back-end. For example, you add a permission, grant it to one of your roles and then write code to check against this permission in your template: if ($user->hasPermission("touch-this")) { echo "The world is yours!"; } else { echo "Can't touch this!"; } So $user->hasPermission() will return true if a user has a role to which this permission is granted, otherwise it will return false. The only exception are users with superuser role as it has all permissions granted by default. For this users $user->hasPermission() will always return true even if superuser role doesn't have a permission granted (checked in back-end). Deleting a permission is like taking it away from a role and respectively from all users with this role. So after you deleted a permission, $user->hasPermission() will return false when checking against this deleted permission for all users except ones with a superuser role. This is based on my limited experience, I'm sure there's more to say on this topic. Edit: corrected "front-end" to "back-end".

I'm accessing PW at present and must say I'm really impressed with what I''ve seen so far. +1 for field level access. I use this facility in modx for virtually every client-editable site (using modx plugins). Perhaps I'm stuck in a certain mode of thinking from using modx for so long, and there's more than one way to skin a cat, but I love in modx that I can have a field from which I can easily issue instructions to a template on a per page basis, which must not be visable/editable to the client. It allows me be reuse the same template for quite different pages. For example, in my modx sites I have "content", "preContent" and "postContent" fields. Only the content field is available to the client, the pre and post content fields simply allow me to add instructions to output something specific on a page directly before or after the clients content. Sure, there are other ways to do this (how do you guys achieve this in PW?) but I love this method as it's so simple and easy to edit. BTW, PW looks like an incredibly good piece of kit and the forums seem super-friendly - I love modx and it's been good to me but it doesn't quite feel right sometimes, whereas PW seems to have a nice clean feel to it. So far I think PW has covered all the bases for my needs, except for a form processor for simple validating and re-populating forms. It's possibly a little beyond my coding level but I might just have to have a dig at writing one. Well done PW team, beautiful work.

The answer to this may help others, I hope. It is not ProcessWire (I didn't think it was but I was hopeful someone else might have had some related knowledge that might have helped hence bothering you guys here). I had already spoken to the hoster in this case to work out which php.ini file was to be edited. The answer is interesting and easy: as I was running a website with FastCGI the php.ini file just above the httpdocs location was the one to edit, not the overall one often found in /etc/php.ini. All good, I edited it. But the problem remained. So a call to (mt), the hosters for this site, and they quickly found and fixed a one-time file that stops FastCGI working with files greater than 128KB. They upped the limit for this file to 1GB and so now this site and any others that use FastCGI will practically be controlled by the settings in their php.ini files. Result: all is working beautifully I hope this is helpful to someone else and thanks again PW people for this superb product. Cheers, -Alan