Leaderboard

When using the jQuery datepicker in the backend for each Datetime field the following javascript might do the job. I have used this on front-end level, but it should work fine on back-end too. var setDate, todayDate = new Date(); $('input[name=schedule_date_end]').attr('disabled', 'disabled'); $('input[name=schedule_date_start]').change(function() { setDate = $(this).val(); if(setDate!='') { $('input[type=text][name=schedule_date_end]').datepicker( 'option', 'minDate', setDate ).removeAttr('disabled'); } else { $('input[type=text][name=schedule_date_end]').datepicker( 'option', 'minDate', todayDate ).val('').attr('disabled', 'disabled'); } }); $('input[name=schedule_date_end]').change(function() { setDate = $(this).val(); if(setDate!='') { $('input[type=text][name=schedule_date_start]').datepicker( 'option', 'maxDate', setDate ).removeAttr('disabled'); } else { $('input[type=text][name=schedule_date_start]').datepicker( 'option', 'maxDate', null ); } }); To be able to use custom javascript in the back-end you could use Martijn's "Admin Custom Files" module for that.

I'm not entirely sure I know how to answer all your questions here because it sounds like you may trying to do things with InputfieldFile is may not necessarily be designed for. If that's the case, you may be better off extending it as a new PHP class, or copying its code to new module, rather than trying to achieve these all with hooks. Another thing I'm not sure about is whether you are talking about a front-end or back-end context. If dealing with a front-end context, the ajax uploading will not work. In some cases you may have to disable it on back-end use too (see the commented line below for how to do that). InputfieldFile is really meant to be used in combination with FieldtypeFile and within the page editor. But it is possible to use it outside of that context. Though you will still need to supply it a Page object so it has a known storage location, but the given Page doesn't need to have a files field. Meaning, it can be any Page, even an admin one. Here's an example of how you might use InputfieldFile on it's own: // page the file will be stored with (doesn't have to have a files field) $myPage = $pages->get('/path/to/your/page/'); // optionally set the name of existing file(s) that will be present (or leave it blank) $myFiles = array( $myPage->filesManager->path . 'myfile.txt' ); // file extensions you allow $myExts = 'pdf csv txt'; // -------------------------------------------- // create the form $form = wire('modules')->get('InputfieldForm'); // create the files field $f = wire('modules')->get('InputfieldFile'); $f->name = 'my_files'; $f->label = 'My Files'; $f->extensions = $myExts; $f->overwrite = true; // $f->noAjax = true; // uncomment if necessary $pagefiles = new Pagefiles($myPage); foreach($myFiles as $filename) { $pagefile = new Pagefile($pagefiles, $filename); $pagefiles->add($pagefile); } $f->attr('value', $pagefiles); $form->add($f); // add a submit button $f = wire('modules')->get('InputfieldSubmit'); $f->attr('name', 'submit_form'); $form->add($f); // ------------------------------------------- // process the form if(wire('input')->post('submit_form')) { $form->processInput(wire('input')->post); $pagefiles = $form->get('my_files')->value; foreach($pagefiles as $pagefile) { echo "<p>Your file: $pagefile->url</p>"; } }

You really want to use $pages->count. count($page...) will come back and bite you when you have lots of pages...

Media Manager Released 31 March 2016 https://processwireshop.pw/plugins/media-manager/ Documentation http://mediamanager.kongondo.com/ As of 10 May 2019 ProcessWire versions earlier than 3.x are not supported ******************************************************* ORIGINAL POST ******************************************************* API Example (frontend; will be added to documentation site) Accessing and outputting the contents of the MediaManager field(s) in your template is quite simple. The fields are accessed like many other ProcessWire fields. The fields return an array of type MediaManagerArray that need to be looped to output each media within. Assuming you created a field of type MediaManager named 'media', you can loop through it for a given page as shown below. @note: Each MediaManager object has the following 5 basic properties: DATABASE (saved properties) 1. id => pageID of the page where the media lives (hidden in admin and not important to know about) 2. type => integer denoting media type (1=audio; 2=document; 3=image [for variations this will be 3x, where x is the number of the variation of an original image]; 4=video) RUNTIME 3. typeLabel => user friendly string denoting media type (audio, document, image, video) 4. media => a ProcessWire Image/File Object including all their properties (ext, filesizeStr, height, width, description, tags, filename, basename, etc.) 5. title => title of media (@note: this is the title of the page where the media lives; may or may not be the same as the name of the media file itself). This can be used as a user-friendly name for your media $media = $page->media;// returns a MediaManagerArray. Needs to be looped through foreach ($media as $m) { echo $m->id;// e.g. 1234 (hidden page in /admin/media-manager/media-parent/) echo $m->type;// e.g. 3 (a media of type image) OR 1 (a media of type audio) echo $m->typeLabel;// e.g. 'document' (i.e. type would be 2) echo $m->title;// e.g. 'My Nice Trip' (whose media file could be my-nice-trip.mp4) /* @note: - $m->media returns an object; either a ProcessWire Image (for image media) or File object (for audio, document and video media) - This means you have access to all the properties of that object, e.g. ext, tags, description, url, filename, basename, width, height, modified, created, filesize, filesizeStr, etc as well as associated methods, e.g. size() */ echo $m->media->tags; } // only output images foreach ($media as $m) { if($m->typeLabel =='image') { echo "<img src='" . $m->media->size(100,75)->url . "'><br>"; } } // There's also a toString() method so you can do: echo $page->media; /* All your media will be output wrapped in appropriate HTML tags, i.e.: audio: <audio></audio>; document: <a></a>; image: <img>; video: <video></video>; */ ******************************************************* ORIGINAL POST ******************************************************* The topic of a central media manager feature for ProcessWire has come up several times: https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/ https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42578 https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/?p=42582 https://processwire.com/talk/topic/425-file-manager/ https://processwire.com/talk/topic/425-file-manager/?p=13802 https://processwire.com/talk/topic/425-file-manager/?p=13861 https://processwire.com/talk/topic/10763-asset-manager-asset-selector/ More recently, regarding my Visual Page Selector module, I have been asked several times why the module does not have an in-built feature to upload images. There's two camps on the topic of a central media manager: those who like them (especially those coming in to PW from other CMSes) and those who don't like them (primarily because of the chaotic way some CMSes (dis)organise their media management) . I think that we can have our cake and eat it too! If done the right way, closely following the principles of and harnessing the power of ProcessWire, we can have a well-implemented, organised, feature-rich, site-wide media manager. Introducing Media Manager: (a commercial module) Alongside a number of modules I am currently working on (both free and commercial), I have been developing a centralised Media Manager for ProcessWire. Before you cast the first stone, no, this is not going to be a one-large-media-bucket as in other CMS where it gets very messy very quickly . In the backend things are neatly stored away, yes, in pages. However, those are pages you will not see (just like repeater pages). Before anyone has a go at pages, remember a page is not that thing you see on the ProcessWire Tree (that's just its visual representation); A page is a record/row in the database . For the end-user of Media Manager, all they will see is the 'familiar media bucket' to select their media from. As long as it works efficiently, I don't think they care about the wizardry behind the scenes . The module allows for the comprehensive management of several media types: Audio Video Images Documents Each media type will be handled by its own sub-module so the user can pick and install/choose the type of media management they want. Features include: Access controls Centralized uploads of media Bulk management of media: tag, delete, describe, replace, etc. Bulk upload: zip; scan, single Quick upload in page edit mode Usage stats across pages (maybe?) Etc.. Would love to hear your thoughts and any feature suggestions. I think there's enough demand for such a module. If not, please let me know so that I can instead focus on other things , thanks. How other CMS do it The more efficient (PW) way of doing it

Or little more efficent if(!$pages->count("parent=$page, my_field=0")) { echo "Sold out"; }

https://github.com/adrianbj/ProcessModuleToolkit It allows bulk automated migration installation and upgrading of modules (and their config settings) from one PW install to another, so it should be very handy in setting up new sites with your standard collection of favorite modules and settings. Allows includes batch installing by a list of module class names. Go to the Setup > Module Toolkit and follow the prompts. During the import, you can choose which modules from the collection to import. You can optionally import the module config settings from the source install. The one caveat is if a particular setting includes a reference to a page, template, or field ID, it won't work, but you can easily update this setting on the destination install. Batch install new modules directly from the modules directory with a list of module classnames or URLs to module zip files. You can optionally, automatically update all of the imported modules (if they are in the ProcessWire modules directory) to their latest available versions. It copies the module files so you can use it to migrate modules that are not available in the PW modules directory, or on Github. Great for all those custom helper modules you've created. Full restore feature in case something goes wrong / you change your mind. I maintain a dedicated test PW install for installing and configuring modules which I can then export for use in my projects using this tool. Please test and let me know what you think!

Dynamic Roles are a powerful access control tool for ProcessWire. They pick up where traditional roles leave off, and allow you to assign permissions at runtime based on any factor present with the user. Once a user receives one or more dynamic roles (at runtime), those dynamic roles then specify what pages the user can view, edit, or add children to. If traditional roles are a sledgehammer, Dynamic Roles are a scalpel, allowing nearly any finely tuned access control scenario. Traditional ProcessWire roles are limited to assignment of view/edit/add access on a per-template basis. Dynamic roles go outside those limitations and enable you to assign that access based on any factors present with a page (i.e. match any field values). Dynamic Roles assign new access, but do not revoke existing access provided by traditional roles. As a result, Dynamic Roles can be used together with traditional roles, and the two work beautifully well together. Though Dynamic Roles can also replace all situations where you would use traditional roles for access control assignments. If using Dynamic Roles to assign page-view access, you would typically want to use traditional roles to revoke view access from at least the "guest" role at the template level. Then use Dynamic Roles to assign view access to those pages in a more granular manner. This module directly affects the results of all page getting/finding operations by applying the access control directly to the database queries before pages are loaded. As a result, it is fast (regardless of scale), pagination friendly, and requires no further intervention by the developer other than configuring the dynamic roles as they see fit. Because it relies upon new features present only in ProcessWire 2.4.6+, it requires the current dev branch. Sponsored by Avoine Concept by Antti Peisa Code by Ryan Cramer PLEASE NOTE: This module is in pre-release state (like the PW dev branch it requires) and is not recommended for production use just yet. Though we do appreciate any testing and/or feedback that you are able to provide. While not required, this module benefits from ProFields Multiplier. If you have ProFields Multiplier installed before installing this module, it will make this module more powerful by making all of your access control selectors have the ability to use OR-group conditions. Depending on your access control needs, this enables you to accomplish more with fewer Dynamic Roles. How to install Make sure you are running ProcessWire 2.4.6 (dev branch) or newer. Download from GitHub (we will add this module to the Modules directory later). Place all files from this module in /site/modules/DynamicRoles/. In your admin, go to Modules > Check for new modules. Click "install" for the Dynamic Roles module (ProcessDynamicRoles). Click to Access > Dynamic Roles for the rest (see example and instructions below). Example and instructions Lets say you ran a Skyscrapers site and wanted a role enabling users with "portmanusa.com" in their email address to have edit access to skyscrapers designed by architect John Portman, with at least 40 floors, and built on-or-after 1970. Yes, this is an incredibly contrived example, but it is an example that also demonstrates the access control potential of this module. 1. In your admin, you would click to Access > Dynamic Roles. 2. Click "Add Dynamic Role". Enter a name for the dynamic role, like: "skyscraper-test-editor" and save. 3. Under "Who is in this dynamic role?" section, click "Add Field" and choose: Email => Contains Text => "portmanusa.com". This will match all users having "portmanusa.com" in their email address. 4. Under "permissions" check the boxes for: page-view and page-edit. 5. For this contrived example, we will assume the user already has view access to all skyscrapers, so we will leave the "What can they view?" section alone. 6. For the "What can they edit?" section: Click "Add Field" and choose: template => Equals => Skyscraper. Click "Add Field" and choose: architect => Equals => John Portman. Click "Add Field" and choose: floors => Greater Than Or Equal => 40. Click "Add Field" and choose: year => Greater Than Or Equal => 1970. 7. Click Save. Now users matching the conditions of your dynamic role will be able to edit the matching pages, but not any others (unless assigned by traditional roles).

Hi, I don't know if this is the right section for this but I collected some thoughts and a kind of manual about how to increase the performance of your website under load with nginx and fastcgi_cache. At best, this could be a kind of ProCache for nginx users, as not everyone is using Apache and thus not able to use ProCache on their sites. Additionally, this solution comes with the benefit of server side mobile detection and selective caching. http://svn.matthiashaak.com/website-performance-with-processwire-nginx-and-fastcgi_cache/ Please let me know your thoughts or questions about this. Be aware however, that with this solution you end up serving static pages, so no hooks or PHP functions will be called. I am currently working on a module that eases the cache purging, so kindly be patient if you need this. "Wait, and thou shalt receive"

Maybe an ajax loaded pagelistselect (like children), where one can select a page, where the current page should be sorted after on save or when some own submit button is clicked.

I don't know but manually sorting 400 pages uff..? Some kind of sort integer field to enter position in a field. Build an custom admin page for that? It's not easy anyway. And experiment with maybe grid instead of a 1 column?

Do you have any showif or requireif values set for any of the repeater fields?

$i = 0;//set counter $out =''; $checked = ''; foreach($foo as $bar) { if($i == 0) $checked = "checked" //radio button stuff here...+ stuff with $bar... $out .= "<input type='radio' name='my_radio' value='{$bar}' {$checked}>"; $i++; } echo $out;

Yes, I noticed that you mentioned "current page" so I thought there's no need to use get(). @kongondo Thanks, I always suspected this but never really dived into it

Please check the permissions on the newly created pages.

My apologies - I hadn't even read your full post before recommending it. ;-)

Hi guys, Thanks for the feedback and advice. I didn't think my way was going to be the best way to do things. I'll have a look at the modules suggested and see which one best fits my situation, on quick glance the CroppableImage one looks good, but I will need to test it out. Thanks again.

Great Idea! I would love to see this one. Do you have some kind of timeplan for it?

Hi StephenOC, Welcome to PW and the forums. What LostKobrakai said. Also wanted to add that ProcessWire resizes and caches the image (the variations you request) once to avoid doing it subsequent times

It's best to handle the actual resizing in code, but something like 3k x 1k images certainly shouldn't be resized on client requests. There are various topic here on the forms and two module (Thumbnails and CroppableImage) which handle resizing of images on upload rather than on request. Also for such large images you'd need to make sure the server does have enough ram available for php to actually process those images, because the images need to be loaded uncompressed into the ram (around 30 MB only for a single image of that size).

Or use new $sanitizer->pageNameTranslate(str)

To clarify Soma's answer a bit: $newNameSave = $sanitizer->pageName($newName, Sanitizer::translate); It's a class constant not a string.

Try without the "".

Andrey, sort by the real name of the database column (in your case it is 'data') and it will work, i.e. $query = 'template=mytemplate,sort=myfield.data';//data here = real name of the mysubfield, not its alias At the moment, I don't know how to tell sort to sort by the alias of a subfield...Searching using an alias (if set) works fine though, e.g. $p = $pages->get('template=mytemplate, myfield.mysubfield=whatever');

I'm using it with insertBefore the image field and it works fine, regardless of PageStatus. I also have added two lines to the AdminCustomFiles/AdminThemeXXXXX.css files to move it to the right: #wrap_hook_sort_images { float: right; } #wrap_hook_sort_images:after { clear: both; } Such a nice and helpful snippet from @LostKobrakai, I really love it.

While it would be possible to inject in memory pages, I don't want to go that route for various reasons. What I do is add a dummy page as you mention. Then add a field "exturl" to the template. Then enter the url in that field like "/path/to/file.php". In the navigation code you then use "exturl" in the item_tpl: $options = array("item_tpl" => "<a href='{exturl|url}>{title}</a>');

Is this subfield stored in the db or just runtime generated? When you're not using limit in the selector you could try to sort the result in memory after getting it from the db.

If you upload a random txt or html file to your web server, can you access it at the other domain? My guess is yes. If so, it sounds like an honest mistake. Perhaps you are on a dedicated IP and the owner of the other domain made a typo when setting up their DNS record. Or perhaps the web host made an error when setting up their VirtualHost directives in Apache. You should be able to correct the problem by adding this to your .htaccess file somewhere after the "RewriteEngine On" line: RewriteCond %{HTTP_HOST} !^www\.yourdomain\.com [NC] RewriteRule ^ http://www.yourdomain.com/ [L,R=301]

Since a while I notice a problem close to yours. It happens just in case of superuser. Adding some custom fields to the user template results in inability to change the values via Admin->Access->Users as loggedin Superuser (id=41). It works with ProcessProfile. After changing values of a specific field one time in Profile it becomes possible via Admin->Access->Users too. Editing other profiles works all the time. Couldn't find the cause. Edit: 5.07.15 Allowance to edit user fields of the current user is based on the cofiguration in Module settings of ProcessProfile. If you have unchecked a field, you can't edit this field. This is default for custom fields. Change the settings in the module to give edit permission for these fields.

Hi everyone, Just added some new features (not in the repo just yet), but wanted to get some feedback on a new name for the module. It still functions as a way to migrate modules and their settings from one PW install to another, but now also includes: batch download and install modules from a list of class names entered in a textarea field batch module updating Name ideas: ModulesManager wouldn't be bad, but already taken ModulesMigratorInstallerUpdater would be the most accurate, but obviously ugly ModulesInstaller is OK, but doesn't cover everything ModulesHelper ? ModulesToolkit ? Free like for any suggestions Here are some screenshots for inspiration: THE OPTIONS EXPORTING INSTALLING (FROM MIGRATED ZIP) INSTALLING (FROM LIST OF CLASSNAMES) BATCH UPDATING MODULES WITH AVAILABLE UPDATES

Hi 3fingers, I'd try taking AutoDetect language out of the picture at first, just to make sure the other part is working. Maybe try testing using a separate browser, or 'incognito/private browsing' tab, so that you're not logged in or anything. In case it helps, here's full module code I used: <?php class LanguageDefault 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' => 'LanguageDefault', 'version' => 1, 'summary' => 'A work around to changing the default language.', 'href' => 'https://processwire.com/talk/topic/9322-change-default-language-for-homepage/?p=89717', 'singular' => true, 'autoload' => true, ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->session->addHookBefore('redirect', $this, 'setDefaultLanguage'); } public function setDefaultLanguage($event) { if ($this->page->id == 1 && $event->arguments(0) == $this->page->localUrl('default')) { $event->arguments(0, $this->page->localUrl('fr')); } } }

Hi, Here is what you can do to redirect the home page '/' to the French home page: Set page names for both languages for the home page ('en' for English, 'fr' for French) In the LanguageSupportPageNames settings, choose the option "No - Root URL performs a redirect to: /name/". When you go to the root url '/' it will redirect you to '/en/' Finally, create a module to hook into Session::redirect to force the redirection of the root url to the French translation as follows: public function init() { $this->session->addHookBefore("redirect", function($event) { if ($this->page->id == 1 && $event->arguments(0) == $this->page->localUrl('default')) { $event->arguments(0, $this->page->localUrl('fr')); } }); } The hook checks whether you are viewing the home page, and whether you are redirecting to the English url, and if so, it changes the url to the French url. This solves the problem of the home page. The problem remains if someone has saved a direct link to a page without a language prefix, e.g., '/about/', since this will still be redirected to '/en/about/'.

Hi, finally I had some time to test @renobird modified version of PageEditPerUser and also @adrian HideOtherUserPages modules for my problem. I like to describe my process here for others that deal with the same problem. First “solution”: Modules used: PageEditPerUser 0.0.3 HiddenAdminPages 1.0.0. All users got the same two roles (thanks @renobird for the tip) Roles: editor (edit, add, (but not) delete) editor_sub (edit, add, delete) Because of the installed HiddenAdminPages I can restrict pages for each user. Disadvantage: The more pages/user the site has, the more work it is to restrict pages for a new user. Second “solution”: Modules used: PageEditPerUser 0.0.3 HideOtherUserPages 0.0.1 (Same roles as first solution) As long as the page the user needs to edit got the same name (Page = user-1 , User = user-1) he or she can just edit his own pages, regardless where they are located Pro: Unlike the first solution, you do not need to add pages to a restriction list. This works better if you deal with a lot of pages. Disadvantage: A Parent page needs to named after the user. For me this solution is okay. Third “solution”: As I mentioned in one of my earlier posts, a solution without any modules would be to have a template for each user and a role for editing just this template. No modules used Pro: Well, it works. ;-) Disadvantage: When you deal with, let say, 50 users, you also need 50 roles and 50 templates. A little bit confusing in the template/roles area. I guess you probably also have 50 files in the site folder on the server? You have to optimize/prepare your templates before you add them to processwire to be aware of future changes inside the template files. Big problem: So far all three solutions would work somehow, and I would prefer solution 2 for my problem but I discovered a new “problem” with solution 1+2. I had a test what happens when user 1 enters the name of user 2 in the search field of the backend. Processwire finds the Parent page and shows an “edit” in the search results. The same happens when user 1 enters a name of a child page that is only visible to user 2. Example user 1 enters "Blau" in the search field. user "Max Muster" also have a page named "Blau". So, in the search results both pages are visible and can edited by user 1. As a result when user 1 knows how the pages of user 2( or any other user) are called, it’s easy to find them and edit them. I got tears in my eyes. ;-) As solution 1+2 works for me somehow both are not usable from the view of security. Maybe I did something wrong here, not sure. The easiest way would be to restrict the search in the backend to just the pages the user can edit (as part of the modules of solution 1 or 2). Any thoughts on that? Thomas

Check for "rewrite_module" in your Apache setting. Should be off by default, turn it on then. https://www.dropbox.com/s/pictxyby393pmdd/rewrite.jpg Was that useful?