Leaderboard

Another German article about PW. This time by a huge hoster (300.000+ users): https://www.df.eu/blog/2015/05/11/processwire-ein-cms-mit-besonderer-flexibilitaet/

I did another quick module, which plugs something I always kinda missed in ProcessWire. It's just a raw overview over the access management from the templates. Nothing fancy, but useful. The visible roles and the visibility of system templats can be setup in the modules settings. I'll add this to the modules directory later. But for now it would be great to hear if anyone is missing anything or if someone does have a better idea how to name the module. 12.03.15: Renamed the module and fixed wrong information for superusers and inherited rights from the required guest role. GitHub: https://github.com/LostKobrakai/ProcessAccessOverview

Another small, but potentially helpful module. This fieldtype references a field in a page, where the field's data is retrieved from a somehow related remote page. It's kinda like a one way symlink to a remote field. To make this description a little easier to understand I'll just add a example. Imagine you've some pages placed all over the page-tree, but you need editors to be aware of a specific setting in a single page. With this Fieldtype you would set this up like this: - Get the page (php snippet kinda like for page fields) return $pages->get("/special-settings-page/"); - Setup template to field pairing settings=my_special_field - Add this field to any template you need this on. Now this special setting is visible in the backend, if someone edits a page with this reference field, and via the api as read-only field. The field can use all collapsed modes, which do not allow editing, so it can be hidden if it's only needed by the api. This can be useful for content heavy sites, where information is scattered around multiple (parent) pages, but maybe all information needs to be available for the children. It's also nice for creating (shorter) selectors for inputfield dependencies or dynamic page fields. More elaborate examples about this options can be found in the readme of the module. Todo Add checks to prevent infinite loops Maybe make it a field, which can be edited and saved. GitHub: https://github.com/LostKobrakai/FieldtypeReference

Pushed a small update, which removes path-details when access rights are not available, as it would falsely suggest that only under this path a role would have no access. Also added a bit of a description about how templates are distributed over the tabs. Also made the module officially 2.6 compatible.

And the rest in the beard !

@pwired Surpricingly the database aint that big, only 6.3 MB.

Thank you adrian for your great work on this module. It's a full blown batch child editor suite for flexible CSV Imports - in as a minimum reward for your work i did the complete german translation, to get more users involved on this module and it's advantages. Kind regards mr-fan 1. did a PR on some strings that lost via c&p the settingsstrings at the end of the module https://github.com/adrianbj/BatchChildEditor/pull/3 2. only one problem with two strings that i can't figure out since i see no difference between the working one and the two others...screenshot added 3. languagfile as zip attached deutsch-batcheditor.zip

Or use http://modules.processwire.com/modules/fieldtype-crop-image/ or https://github.com/horst-n/CroppableImage to generate the pre-generate the needed thumbnail sizes and call them directly int the template like // get the first image instance of crop setting 'portrait' $image = $page->images->first()->getCrop('portrait'); regards mr-fan

Page Field Edit Links GitHub: https://github.com/thetuningspoon/AdminPageFieldEditLinks Direct Download: https://github.com/thetuningspoon/AdminPageFieldEditLinks/archive/master.zip This module is based on--and is the successor to--Macrura's AdminPageSelectEditLinks (https://processwire.com/talk/topic/8477-adminpageselecteditlinks-module-for-enabling-edit-links-on-multipage-selects/) Page Field Edit Links adds modal editing capability to ProcessWire's Page fields in the admin editor, allowing editors to easily view and edit the content of any page(s) that have been selected, as well as create new pages without leaving the current screen. Edit links are updated in real time when new pages are added to the field. Compatible with all available types of Inputfields including Select, SelectMultiple, Checkboxes, Radios, AsmSelect, PageListSelect, PageListSelectMultiple, and PageAutocomplete.

Hey, if I'm using the Language Translation Tool strings automatically get deleted if they match the original string. This is really annoying because it shows those strings as "blank" in the overview but you can't fix them. Why not just let them be as you type them in? - Nico

Thats not a beard, my chin just hit puberty

OK, I think they need to be treated as separate translatable strings, like this: $fieldEnabledTemplates->description = __('The batch editing option will only be available for the selected templates . '. "\n" . __('NB Leave blank to allow all templates.', __FILE__); Or using $this->_() it would look like: $fieldEnabledTemplates->description = $this->_('The batch editing option will only be available for the selected templates . '. "\n" . $this->_('NB Leave blank to allow all templates.', __FILE__); Seems a shame to have multiple strings to translate though just because there is a line break, but as far as I can tell there is no other way. Or maybe it actually makes more sense so the translator can't accidentally remove the line break?

want to say many thanks to @thetuningspoon for putting this together, and doing all the work of submitting to the directory. It's surely a useful module (use it almost every site), and we hope that all y'all will like it..

Thanks for testing. I'd probably be OK without the line breaks in those spots in your screenshot, but what about this line for example: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L1198 - this definitely needs the line breaks. It seems like this should work. Could you please confirm? $fieldEnabledTemplates->description = __('The batch editing option will only be available for the selected templates.'."\n".'NB Leave blank to allow all templates.', __FILE__); I probably should switch them all over to: $this->_() for the speed advantage since they are all inside a class, but that can wait for now.

Sorry to hear that. Could you please provide some additional information (pw version, 3rd party modules, serverside software), as I'm not aware of any other recent issue report like yours.

Thanks for the kind words and for your efforts on this translation - must have been quite a task - there's lots to translate in this module I accepted your PR and also fixed (I think) the issue you were having translating that the enabled templates setting description. Please let me know if it works now.

Crosslink for the translation of the BatchChildEditor module. It's a swissarmyknife for CSV Imports and batch child page editing... https://processwire.com/talk/topic/6102-batch-child-editor/page-2#entry94729 best regards mr-fan

I gladly take a look cause I have no idea what is the problem. Or you guys having problem could try modifiying module https://github.com/somatonic/Multisite/blob/master/Multisite.module#L43 To this: $this->subdomainsArray = explode("\n", strtolower($this->subdomains));

Escaping (or entity encoding) of output can be done automatically at field level. Take a look at the 'Details' tab on e.g. a textarea field like the standard 'body' field. Under 'Text Formatters' you should see 'HTML Entity Encoder (htmlspecialchars)', which applies http://php.net/htmlspecialchars to the field's content when output. Depending on the sources of your field data, this might not really be necessary - if you absolutely trust everything you could be outputting it probably isn't. On the other hand...

Hello, in PW I really like possibility to dynamic resize images in template, but also maybe - one day - there can be and option for multiple thumbnails creation over upload process. Also in some cases cron jobs (background server scheduled tasks) are solution. regards, Sasa

So today found a new strategy for building processwire website and it's more awesome than all the strategy in place, because it allows you to easy modify codes without bothering about appending to content or pre-pending to content, will write a tutorial about this. ever since i discovered wireRenderFile(), it made things easier for me. Will drop a tutorial soon, please keep this post in mind.

Guys, I implemented sisyphus.js as a module. You can test it from here https://github.com/ocorreiododiogo/Local-data-saver-Processwire To test, edit one or more fields in a page and open that same page in a new tab without saving. The data should magically appear there I didn't test it thoroughly, so, proceed carefully. In this implementation, all changes will be saved to local storage until the from is submitted. after submission the local storage is cleaned. Ideal implementation would have a visual clue that the data was loaded from local storage, and not from the db, and would have a button to clean the local storage and replace it with the real data. PS: I can see some cases where this can cause confusion with multiple users, but currently it can also happen without the module.

Thanks for working on this. I'm using this with a few of my internal websites (where I routinely keep my clients updated on their technical support, consulting or web development issues). The level of detail you have in this module is appropriate for this purpose and has been very helpful.

http://eressurs.no/no/processdisplay/

So here we go, Manfred62 asked me to push the german translation fo this great addon for processwire...and deliver it with the PW language files on github. So i started tonight - and fin some little things here and there. Done a pull request on git for the first one i found: https://github.com/kongondo/Blog/pull/20 added two pics that show the difference... for the germant translation i'll take some free evenings since with the installer there is much more text than the first versions By the way install 2.3.4 runs great and module is for shure great, too!! Best regards to Kongondo for this big piece of work - glad to could contribute a little with some lang files!

It does not save the real value of the field, but only the textual representation. That's why it's not like version control.

Looks really nice, good stuff Tom, I'm gonna install this and give it a burn when I get a minute. I realise you mention it's not version control, but if all changes are recorded (even text areas) as they appear to be then I'm guessing it's possible to add a roll-back feature to crank a field back to a previous version?

You could just alter this to your needs. This adds a second button to the pageEdit, which then triggers an action if clicked. <?php class HookPageEdit extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hook PageEdit', 'version' => 1, 'summary' => '', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'addButtons'); $this->addHookBefore('ProcessPageEdit::processInput', $this, 'addButtonsMethods'); } /** * Add a button besides "Save", which lets the user accept the application * */ public function addButtons($event) { $page = $event->object->getPage(); if($page->template == "application"){ $form = $event->return; $accept = $this->modules->get('InputfieldSubmit'); $accept->attr('id+name', 'hook_accept_application'); $accept->class .= ' ui-priority-secondary head_button_clone'; $accept->attr('value', $this->_('Accept Application')); $form->insertBefore($accept, $form->get("id")); } } /** * Triggers the pageAction of "PageActionAcceptApplication" if the page was * submitted via the added button. This won't save the page, because that only * happens if the button is named "submit_save" or "submit_published" * */ public function addButtonsMethods($event) { if($this->input->post->hook_accept_application){ $page = $event->object->getPage(); $event->replace = true; if(!$page->id){ $this->error("Invalid application to be accepted."); return; } $accept = $this->modules->get("PageActionAcceptApplication"); $accept->action($page); } } }

Hi everyone, I did a little thinking and coding on this issue last night. There is a gist on this post (https://processwire.com/talk/topic/8605-user-editsaddsmove-only-his-own-page/?p=84835) which hides uneditable pages, but be sure to read my comments in that post. And based on my comment about the issues with "is editable" checks and the need to display non-editable parents to allow a user to access editable grandchildren, here is a much more comprehensive module that allows the ability to hide specific pages (and obviously their entire branch of children/grandchildren) based on the user role. It is based off my Page Protector module so it will look familiar to anyone who have used that. It is just a first draft, so test carefully It is attached here for now. Any thoughts? AdminPageHider.zip

Ha! I didn't notice that . Well I hope I said something useful

hey guys, thank you! it worked for me with the following values (for testing): index.php ini_set("session.gc_maxlifetime", 60); // changed $config->sessionExpireSeconds to 60 config.php ini_set('session.gc_probability', 100); // 100% probability ini_set('session.gc_divisor', 100); ----> it cleared all session files older than 60 seconds on every pageload.

Reviving this old thread. Luckily, since I'm only getting into PHP now, by going straight to OOP, I've not really had to unlearn some procedural PHP in order to grasp OOP. I found the following helpful: http://net.tutsplus.com/tutorials/php/object-oriented-php-for-beginners/ http://www.tutorialspoint.com/php/php_object_oriented.htm http://phpro.org/tutorials/Object-Oriented-Programming-with-PHP.html http://www.codewalkers.com/c/a/Programming-Basics/ObjectOriented-PHP-Fields-Properties-and-Methods/ http://www.massassi.com/php/articles/classes/ http://net.tutsplus.com/tutorials/php/from-procedural-to-object-oriented-php/ http://net.tutsplus.com/tutorials/php/real-world-oop-with-php-and-mysql/ PHP Academy tuts - videos

Ok since you hook Page::viewable every page in PW will be somehow affected, even admin pages as they are also just pages. So the message with $event->object->name is the admin pages rendered in the admin template. I'd guess it's the navigation. But since the ProcessPageList module is ajax driven you won't see any messages from there. $event->arguments is nothing there I think, as the important with these page access hooks is the $event->return value. So you would do set it to false or true $event->return = false; // page won't be viewable All the viewable hook does is define if a page is viewable or throw an 404. In case of the admin page tree the page will still be visible and only have no -view- action button. That's all. If you really want to hide pages in the admin I'm with Ryan, but see that there's cases where it would be nice to hide pages from users and keep a branch hidden from them. I already stumbled and tried very hard 1-2 years ago, but realized it's not easy as there's no obvious hooks available where needed and it's done with ajax and there's some things to consider, didn't really bother. Now after thinking for some time and try error I found an easy way to just remove pages from the page list tree. The trick is to modify the JSON output that goes with the ajax response, convert it to an array and Long story short here's an example module for those interested. I used a pagelist_hidden page field added to the user template to define pages that are hidden for a user. Of course there could be endless configuration possibilities, with roles and what not, but don't want to go any further and maybe someone else finds this useful or as a start for a new module. If Ryan reads this and is still with me. Would you consider adding some hooks to ProcessPageList.module? Or do you think the JSON manipulation is a good way? Most likely there would have to be some additional take care to make those pages also not editable. Those page will still be accessible manually through admin url. Such a module shouldn't be used to hide pages for access restriction, and it's only and best suited for hiding "private" branches in the admin, or functional pages that can't be in the /Admin/ branch for some reasons.