Leaderboard

if you want to search the forum for interesting things, best is to use google with a search like this site:processwire.com/talk -"Viewing Profile" fieldset The part site:processwire.com/talk and the -"Viewing Profile" part are what I use every time, appended with my searchterms I actually looking for. If you use this, you will get many useful links like: https://processwire.com/talk/topic/1057-template-editor-fieldset-indentation-and-checkbox-columns/ https://processwire.com/talk/topic/176-fieldsetopen-fieldsettabopen-%E2%80%93-what-is-it/ https://processwire.com/talk/topic/665-editing-fieldsets/ https://processwire.com/talk/topic/7608-fieldset-grouping-in-admin/ The ip.board searchfield is not helpful. You can also use the google serach with /docs/ instead of /talk/, if you want to quick search in API and other docs. Happy reading!

So true! He's possibly a before hook on topic::render

Greetings, I build many of my ProcessWire applications entirely with front-end admin areas, and allow access to the back-end only for super-users. If I understand what you are asking, you just need to adjust some access settings for the "admin" template to get what you want: From main admin screen, go to "Templates." Set "Show System Templates" to "yes." Choose "admin" template. Under "Access" tab, set "Do you want to manage view and edit access for pages using this template" to "yes." Under "What roles can access pages using this template..." un-check all roles. Under "What to do when a user attempts to view a page and has no access" choose what you want to do. I use this to redirect to my front-end login page. From the main admin screen, go to Access / Roles and un-check the "Page-Edit" permission for all roles. Of course, this is only good if you want your users working entirely in the front end. Also, if you re-direct to your front-end login page, even super-users will be redirected there. But super-users will be able to then go to the back-end. Thanks, Matthew

This seems to work on all inputfields for me: $this->addHookBefore('Inputfield::render', function($event) { $field = $event->object; $field->setAttribute('ng-model', $field->name); }); EDIT: Oops - well and truly beaten Can't afford to sidetracked in the middle of replying with when @LostKobrakai is online!

@Nukro, here's a little mindset: The PW back-end is build on top of the API. The PW front-end is build on top of the API. In fact, you don't need the back-end at all to run ProcessWire. The backend is full of access checking and stuff, but when you do create, read, update & delete stuff on front-end you need to do that access stuff yourself. The back-end is full with JS and CSS stuff that is needed for proper functioning, ajax request etc. etc. And again if you want that on front-end, you need to include that if possible or create it your self. For user access & permissions I gladly point you to http://processwire.com/api/user-access/ to get the insight of the role based access control system.

Looks like saving the Page 'quietly' is sufficient. <?php // 'quiet' => boolean - When true, modified date and modified_users_id won't be updated $pages->save($your_page, array(quiet => true));

The form api of processwire isn't meant to be used in the frontend, therefore I doubt there being any updates like that. But you can add that functionality on your own. $wire->addHookBefore("Inputfield::render", function(HookEvent $event){ $inputfield = $event->object; $inputfield->attr("ng-model", $inputfield->name); });

From within a template its simply: $thisone = $pages->get('/some/page/'); $pages->delete($thisone); // or $pages->trash($thisone); You might want to do some check ups before if($thisone->deleteable() && wire('config')->demo == false && $thisone->rootParent != wire('pages')->get('/trash/') && $thisone->rootParent != wire('pages')->get($this->config->adminRootPageID)) { // delete or trash } ps. taken from the ProcessPageDelete module https://github.com/NicoKnoll/ProcessPageDelete/blob/master/ProcessPageDelete.module

I can only point you in the direction how i would go about it. I would create a simple module, that only has one function and that is to redirect the user to the home page, once he is logged in to the manager. In the module method getModuleInfo() make sure the module only runs on the backend side by setting 'autoload' => "template=admin" In the module init() function do something like this public function init() { // only company role, else do nothing if(!$this->user->hasRole('company')) return; // redirect to home page or call a 404 here }

If someone wants to get an image field rendered as picture element, use the excellent ImageToPicture Module from johannesdachsel.

Google today announced it's competitor to Facebooks "Instant Articles": "AMP"(Accelerared Mobile Pages)HTML. Based on open source technologies (Basically it's a set of Web Components and a JS-Framework that loads and caches resources) it seems very promising. As far as I understand media is cached, served and proxied by google (and some tech partners). Btw: processwire as a system could benefit from/partner with it, too: https://www.ampproject.org/faq/#accelerated-mobile-pages-9 I'm really looking forward to playing around with it. Anyone else already fired up his editor and started fiddling around?

We have to make the world know! Discuss and upvote: https://news.ycombinator.com/item?id=10345280

If it wasn't for mobile app development I probably never would have made the switch to Mac, but now that I have, I probably won't go back, just because of the UNIX base and also because I am now comfortable with the toolset I am working with. That doesn't mean I am thrilled by Macs - in my mind they are just a different set of problems

It's clearly not just you, but.. nope, they didn't On a (slightly) more serious note, I have to say that after a few years with OS X I would find it very difficult to switch back to Windows. OS X has a bunch of neat features (such as the Spotlight search, which in my case has literally eliminated the need to touch menu items or Finder ever again), but a much bigger benefit is that it's Unix-like. If I need to automate a task or two, can't figure out how to do this or that via the GUI, or just want to get things done without swinging a goddamn plastic rodent all over, I can always just step into the soothing darkness of the console and get shit done. OS X is the next best thing after Linux, and since Linux still doesn't have most of the apps I need, it's the best thing at the moment. The new Surface Book does seem like a splendid machine, of course. Compared to a MacBook Air it looks a bit clunky, but from a strictly technical point of view it does seem quite awesome. If I actually had to get a Windows laptop, this just might be it

Thanks for that Adrian! No, the issue is not tied with the ImageExtra module, I installed that one in an attempt to find a workaround - adding another field to hold the description, but those fields started malfunctioning as well. Most recently it's happened on a website which had the CropImage Module installed, with ProcessWire version 2.3. But the issue is not affecting only CropImage fields, but normal image fields too, which leads me to believe it might be a problem with the core image field, which all of these other fields extend (if I understand correctly how modules work). Upgrading PW and all modules to the latest stable version did not fix things (as I hoped), btw. EDIT: right now I have created a new CroppableImage field and copied all the content for each page into it, but I left the malfunctioning field in place, to provide a subject for analysis. So far the new CropImage field is holding, but it did bug out the first time I was copying the content over about half-way through - and I had to start over again by deleting it and creating a new CropImage field. I learned something that way - if I delete a bugged image field and then re-create it with the same name, the problem persists (the description field still doesn't work) - I had to give the new field another name.

Have just bumped the dev branch up to 1.3.4, bringing several important updates to be merged with master soon. Firstly, and most importantly: In light of PW 2.7 being around the corner, the minimum PW version requirement is now 2.6.1. This allows the use of 2.6 goodies that were not used before. Mainly, Jumplinks now uses ModuleConfig. Next, the Entity Editor (the name used for the jumplinks editor page) is now working as expected. PageListSelect and PageAutocomplete are now syncing correctly. This is really just a visual gimmick for the purposes of consistency. The editor now looks much cleaner, and easier to use. Few other changes to note: Table font size has been increased a notch. Destination column now has page title and full path hint for jumplinks that reference existing pages. Table footer has been removed - I don't think this was very informative, and thus not needed. Please note that I have not tested everything extensively as yet - this will be done soon. As such, don't use this branch on a production site until merged with master. Once merged, I'll bump the version up to 1.5, considering the major changes/departures compared to the current 1.3.x.

Seem to have got it working. Really hacky, but it does the trick. (Keeping in mind, here, that this is really just a visual gimmick...) $('#destinationPage').on('pageSelected', function(a, b) { if (b.id > 0) { $('input#destinationUriUrl').val('page:' + b.id) $('#destinationPageAuto').val(b.id); $('#destinationPageAuto_input').attr('data-selectedlabel', b.title).val(b.title); } }); $('#destinationPageAuto').on('change', function(b) { if (b.currentTarget.value) { $('input#destinationUriUrl').val('page:' + b.currentTarget.value); $('#destinationPage').val(b.currentTarget.value).parent().find('.label_title, .PageListSelectName').text($('#destinationPageAuto_input').attr('data-selectedlabel')); } });

Not 100% sure, but besides the default admin theme, the RenoAdminTheme, that is shipped with the PW core, seems to be the only public one at the moment. But there are also possibilities to only change the colors of those Themes or to fork and slightly modify them. For this, please refer to some threads: https://processwire.com/talk/topic/7625-reno-theme/ https://processwire.com/talk/topic/7238-release-apertusadmintheme/ https://processwire.com/talk/topic/8226-my-backend-redesign/

Honestly, I don't think it's necessary to reproduce the grid in the backend unless there is a very spacial need. Users can take a certain level of abstraction and can easily understand that, in a list of images, te first five will be the first row and so on. You can limit the amount of images in the field to 50, but you can also do it at template level when calling the field ("limit=50"). Because this field will have many images, you can have "grid" as default view in the field settings. If you think it's less confusing for the user, and since you'll have a fixed number of rows, you can also create 10 different multi image fields named "row1, row2..." and wrap them inside a field set.

I think I know what you mean. Try changing line 119 in AdminPageFieldEditLinks.module from this: $newPageParent = $event->object->newPageParent ?: $event->object->parent_id; to this: $newPageParent = $event->object->newPageParent; Now just make sure that you are specifying a particular template and don't select a parent for new pages. Now when you click "New" it should now ask you where you want to put the new page, based on the template's family settings. I haven't tested, so let me know if that works.

http://www.lovemysurface.net/run-linux-on-surface-pro-3/ Should be possible on the Pro 4, too

Hi there, today I was playing around with Bootstrap 3.1 and PW. I downloaded a boilerplate template for Bootstrap3.1 from initializr. Then I took a virgin PW 2.4 install and merged the initializr files with the files in PW template folder. I didn't touch any of the content and tried to replicate the site-default template as close as possible with Bootstrap markup. Only thing I added is a carousel instead of the random image. The result is a default PW install with Bootstrap look. For the main menu, I took Damienov's rendering function from here. To install my template: 1. Do a default PW 2.4 install 2. Unzip the attached file 3. Replace the original site/templates folder with the one from the attached zip file. The result can be seen here: http://pwboot.webseiten-fuer-alle.de/ templates.zip

Noooooo! Do not walk into the light. It is a trick! I walked away from winblows in '03 and never looked back. Now I sleep well too.

thanks for posting, not seen this. First look, it sounds interesting but not really sure what they're trying to solve with it... also the first quote is worrying as it is mianly focused on advertising

Linode is amazing and has datacenters in Tokyo and Singapore

@adrianmak, Consider https://www.padloper.pw/ as it is beautiful and cheap

...and the module will not be updated: As for you question, I don't have an answer.... Edit: Silly me! See much better responses below! Padloper all the way!

Hi (now editing my original question:) I know this is an old thread and most interest is around newer broswers, tho i'm new to PW and needing ie8 support hence liking this theme a lot. oneproblem is it displays differently across firefox (41) - navbar inline as expected - compared with chrome (45) and ie8-11 - navbar right and search navbar-form both sit underneath the navbar-brand and the search form is ?page width. reproduced this on 2 machines. borrowing from the bootstrap docs one fix is replacing the <form> code in site/templates/head.inc line 67... to this: <form class="navbar-form navbar-right" role="form" id='search_form' action='<?php echo $config->urls->root?>search/' method='get' > <span class="form-group form-inline"> <input type='text' name='q' id='search_query' class="form-control" value='<?php echo htmlentities($input->whitelist('q'), ENT_QUOTES, 'UTF-8'); ?>' /> <button type='submit' id='search_submit' class="btn btn-default"><!--span class="glyphicon glyphicon-search"></span-->Search</button> </span> </form>

Ok, updates! Regular asm inputfields now work dynamically without the need for a page save Compatible with the new singular autocomplete fields Links are now fully configurable on a field-by-field basis Implemented preliminary "Add New" functionality to enable adding pages via modal window right from the field Changed "Edit" link labels to "View" (just my preference... but maybe this could be made configurable down the road) Code cleanup and optimization Note that after you upgrade you may have to re-set your page fields (just the edit link checkbox, not the whole field).

I'm personally really not that interested in the development front of php. As long as I have to even switch servers of clients that the minimum requirements for PW are met I can't possibly benefit from anything mentioned there. I'm happy if I have php >= 5.4.

html/scss prototype ... not working as admin theme, it is just html theme

@k07n: The module looks good. But start your class with an uppercase character, otherwise it might confuse PW's module parser, which is expecting it for categorization purposes. @jmart: 301 would really be the right way to do it and would not be a nightmare. Use Apeisa's redirects module and life will be easy. But if you really need all pages to be accessible at root level (which is not something I'd recommend) you could accomplish it by editing your 'home' template, clicking to the 'URLs' tab and enabling URL segments. Then in your home.php template: if($input->urlSegment1) { $p = $pages->find("name=" . $sanitizer->pageName($input->urlSegment1))->first(); if($p) { $session->redirect($p->url); // 301 redirect to it // echo $p->render(); // or output it here, no redirect } else { throw new Wire404Exception(); } } else { // render homepage }