Leaderboard

Until you login, you're an anonymous visitor like every other guy who accesses the site. So if you hide the admin access, how would PW know it was you? Don't worry. Set up a safe password and you'll be fine. If you really want an extra layer of security, change the admin path to something not obvious like dragan suggested. Anything more isn't worth it. The admin path isn't listed anywhere, and is not indexed by search engines (nothing tells them where it is), so the only way to guess it is just that, to guess it. It's extremely unlikely someone would try that unless you're making a site for the government or a huge brand like coca-cola. Also worth mentioning is that if you fail a login 3x, the admin will make you wait 5 seconds before the next attempt. Fail again and it's 10, again and it's 15... Brute-forcing with that protection would take forever. I've mentioned this in various posts in the past about security. I've NEVER heard of a single PW site being hacked.

Hi everyone, Relatively major new version just released: 1) New run on init, ready, finished option in Console panel I am not sure how popular this will be, but it lets you inject code from the Console panel into the PW process at init, ready, or finished. This lets you test hooks and other code that you would normally add to the init.php, ready.php, or finished.php files without having to edit files, and also without affecting anyone else viewing or working on the site. This screenshot should give you the idea: As you can see, I have added a hook to change the page title on saveReady. The way it currently works is that you: enter your code click Run to "register" the code for the next page request select "init", "ready", or "finished" as the place to have it injected In this example, you would then save the current page and the hook would be injected into init() and the page title will change If you don't switch back to "off" when you are done testing, it will expire in 5 minutes. The Console panel icon will also change to a red color to provide a visual indicator that you have an injection running on each page request. Please give me feedback on this feature - if you guys are annoyed by having those options visible and you never plan on using this, I'll make it an option that can be turned off completely. 2) Make User Switcher available without setting to "DEVELOPMENT" mode When I initially built the User Switcher I was a little paranoid about the possible security implications so went a little overboard by making it only available when hardcoded to DEVELOPMENT mode. But in reality this didn't make any difference and just made it more difficult to use, so now you'll find it easier to use - it's such a great feature! If you haven't used it, give it a go! 3) Options to hide debug bar from Form Builder iframe Having the debug bar in a Form Builder iframe can be useful, but also a visual annoyance so now you can disable if you want. 4) Hide User Bar from Form Builder iframe This is automatic as there is no reason for the User Bar to appear in a Form Builder iframe and it is confusing for users and ugly. 5) Restricted panels now works with "tracy-restricted-panels" role as well as permission (needed due to recent PW core change) Due to a recent change in the PW core, it is no longer possible to edit the permissions for the superuser role, so I have now added support for assigning a "tracy-restricted-panels" role to a user. The "Restricted Panels" defined will then be applied to users with this role. The permission option will continue to work for other non-superusers. 6) ACE editor update 7) Other bug fixes / tweaks

Damn that hurts. Like Robin says, check your colour profile on the original image. Also, I've been handed JPEGS in CMYK instead of RGB, and 24 bit instead of 16. These are weird, I haven't seen many, but Trump got elected, Brexit won and the far-right is gaining ground in Europe so... You can also try using ImageMagick for your image processing needs instead of the default GD: https://modules.processwire.com/modules/image-sizer-engine-imagick-cli/ By the way... $featured_image->size(854,0)->url is the same as $featured_image->width(854)->url

Sure diff features: If you have a local version of a PW site you can compare it to the production one in seconds (depending on the connection speed usually in 4-40 seconds), benefits: dead easy to spot new log entries, such us: errors.txt, sessions.txt, etc... easy to apply changes both directions, after all, it is a diff tool helps when doing upgrades: it is possible to compare updated index.php to .index-3.0.x.php, for example. Same goes for wire folder and .htaccess, of course. You can delete what is no longer needed, rename what should be changed right form the diff view window. I usually also delete previous module directories renamed and left over by the upgrade module. You can batch select changed/new files, expand the tree view to see only changed/new files/folders, temporarily see "files/folder hidden by you" etc... all in all it is very fast to manually sync a site. It is possible to temporarily exclude and/or hide files/folders, excluding can be saved as a "permanent session" (can be changed later on, of course) I'm just scratching the surface with this sort description, it has tons of other features, but most importantly if configured properly it is the fastest (by far) of all similar GUI diff tools I've ever tested. Automatic file sync features are good too but I use those less often. I want to write a blog post about my workflow that heavily relies on all the above. I just need to find the time to do that

When I create a new Hanna Code tag I am always creating a PHP tag (I don't think I've ever had a need to create a text or Javascript tag). And I prefer to edit my tag code in my IDE rather than in the code field within the Hanna Code module. Because of this my Hanna codes always consist of... <?php include $config->paths->templates . "hannas/{$hanna->name}.php"; ...which just includes a file named the same as the Hanna tag from a "hannas" folder in /site/templates/ Always on the lookout for efficiencies, I had a go at automating the process of setting up new Hanna tags and come up with the following. Maybe it's useful to someone. In /site/ready.php: // Pre-fill code for new Hanna tags and create file $wire->addHookBefore('ProcessHannaCode::executeEdit', function(HookEvent $event) { $id = (int) $this->input->get('id'); // Include code for later use $file_include_code = '<?php include $config->paths->templates . "hannas/{$hanna->name}.php";'; if(!$id) { // A new Hanna tag is being added // Set type to PHP $this->addHookBefore('InputfieldRadios(name=hc_type)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->value = 2; }); // Set code to include file of same name as tag $this->addHookBefore('InputfieldTextarea(name=hc_code)::render', function(HookEvent $event) use ($file_include_code) { $inputfield = $event->object; $inputfield->value = $file_include_code; }); } else { // An existing Hanna tag is being edited (the new tag has been saved) // Get the data for this tag /* @var \PDOStatement $query */ $query = $this->database->prepare("SELECT name, type, code FROM hanna_code WHERE id=:id"); $query->bindValue(':id', $id); $query->execute(); if(!$query->rowCount()) throw new WireException("Unknown ID"); list($name, $type, $code) = $query->fetch(\PDO::FETCH_NUM); // If it's a PHP tag and the tag code matches the include code... if($type == 2 && $code === $file_include_code) { $filename = $this->config->paths->templates . "hannas/{$name}.php"; // Check if there is an existing file and if not... if(!file_exists($filename)) { // Define the contents of the file // Just the namespace and API variables for IDE code-completion // Some of this is PhpStorm-specific so adjust as needed $contents = '<?php namespace ProcessWire; //<editor-fold desc="API variables"> /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms * **/ //</editor-fold> '; // Create a file and insert the contents above file_put_contents($filename, $contents); } } } });

@msavard have you seen this post? https://processwire.com/talk/topic/3706-how-to-blockredirect-one-user-role-away-from-admin-pages/?do=findComment&comment=46421 Also, there are these modules: http://modules.processwire.com/modules/auth2-factor-ppp/ http://modules.processwire.com/modules/session-login-alarm/

I upgraded jQuery from 1.8.3 to 1.12.1, jQuery UI from 1.10.4 to 1.12.1, datepicker.js from 1.6.1 to 1.6.3 and updated longclick.js from 0.3.2 to 0.4.0 and it works just fine (after few quick tests). Then I tried jQuery 3.2.1 and jQuery Migrate 1.4.1 and it's working too (Migrate is required). jQuery 1.8.3 is released in november 2012. It's nothing wrong with that old version, but it just doesn't fit in the incoming new stable version of PW...

WOW, just today I was thinking of writing an article about clients protecting themselves from agency death. Out of principle, I do the setup but make my clients buy the hosting themselves, give them all pre-compiled code (SCSS, original JS...) and give him the original files for the layout. If I had 1€ for each time a client came to me with and discovered to be in a dead-end with their current site I'd... well almost be able to have a coffee at Starbucks. Almost.

Password Generator Adds a password generator to InputfieldPassword. Usage Install the Password Generator module. Now any InputfieldPassword has a password generation feature. The settings for the generator are taken automatically from the settings* of the password field. *Settings not supported by the generator: Complexify: but generated passwords should still satisfy complexify settings in the recommended range. Banned words: but the generated passwords are random strings so actual words are unlikely to occur. https://modules.processwire.com/modules/password-generator/ https://github.com/Toutouwai/PasswordGenerator

Best and fastest diff+sync tool ever . Period Windows, Mac or Linux Monday, November 27th only. Applies to new licenses and upgrades: https://www.scootersoftware.com/shop.php?zz=shop_promo https://www.scootersoftware.com/features.php?zz=features_list I'm waiting for it...

Thanks everyone for all the tips! Some notes: The screenshot I took shows the image *in PW* on the left (I clicked on the thumbnail in the backend and it opened the lightbox; that's what you're seeing there). So yes, that is a direct comparison of the uploaded image, to the resized image. Looks like ImageMagick requires PW 3.0.10... The site I've adopted is a mess of old modules, and I can't update it past 2.3.0. But... good news! I tried downloading the original image, opening it in Photoshop, using their legacy "Save for Web" export dialog, making sure it's set to sRGB, re-uploaded it, and bam! Thanks @Robin S!

Are you sure you are comparing apples with apples here? In your screenshot, is the original image being viewed in the context of a browser, or is it viewed in some other application? There are so many things that can come into play when you are dealing with colour management - whether the image has a colour profile embedded, what the colour profile is (sRGB is probably the safest option), the colour management support within the application you are viewing the image in, etc. To verify that the colour loss has anything to do ProcessWire's resizing you should insert the original image next to a resized version of that image in a template file and view them in your browser. <img src="/path/to/original-image.jpg" alt=""> <img src="<?= $page->image->size(854,0)->url ?>" alt="">

I think it's a matter of personal taste... Alternative syntax would be something like this: <?php $imgoptions = [ 'quality' => 100, 'upscaling' => false, ]; $products = $page->siblings("id!=$page"); ?> <?php foreach ($products as $prod): ?> <div class='uk-width-1-2@s'> <?php if (count($prod->images)): ?> <a href="<?= $prod->url; ?>"> [... and so on ...] </a> <?php endif;?> </div> <div class='uk-width-1-2@s'> <?= $prod->title; ?> </div> <?php endforeach;?> Furthermore, I normally separate the controller logic (upper part between <?php ... ?> from the view part (lower part) in different two files. In this case, the controller part is very simple, though.

Joomla? We're all pointing at you and laughing. Did you not google? How about this? https://extensions.joomla.org/extensions/extension/access-a-security/site-security/akeeba-backup/

Are there already European developers implementing GDPR in their websites ? The European regulation will be obliged by 28/05/2018. What is it? https://www.eugdpr.org https://en.wikipedia.org/wiki/General_Data_Protection_Regulation It will be obliged to encrypt all personal data fields (name, email, phone, address, ... ) from users, and communicate about it. It would be interesting to implement an encryption setting for fields, just like the password field. That way all data in a database will be useless, unless you have a decryption key. I Think it's some stuff to think about, too meet the European regulation and to make Processwire even more secure.

Cool to have a dedicated option for these, but 3 and maybe 4 have been possible for a while now via the "No Debug Bar in Selected Templates" feature (the Form Builder iframe was what prompted my request for that feature ).

From 2000 to 2015 I had a company that ran its own servers, and I can tell you that either you put yourself in the middle with clients that buy premium service and pay hundreds per month, or its just not worth the hassle. Our tech guy spent his days resetting email passwords and telling clients to check if their wifi was on. If you're taking a 5€ profit, one call is enough to burn it. For me the best deal is to talk to the hosting provider, show them how much business you're bringing them, and use that to negotiate free hosting for yourself.

Thanks for listing that up. I guess I have to try beyond compare and see any winning time above a frugal way of working.

@Alex CA you can change those fields when you instantiate the module: $rss = $modules->get("MarkupRSSEnhanced"); $rss->title = 'Title for this feed'; $rss->description = 'Description for this feed'; $rss->itemDescriptionField = 'r_desc'; // set your specific field here, e.g. r_desc or e_desc $rss->itemEnclosureField = 'r_pic'; // or e_pic $limit = 8; $items = $page->children("limit={$limit}, sort=-publish_start"); $rss->render($items);

Can you give some examples where you are using it ? I gave up on database comparison local/online because it's too time consuming. I also stopped with website file syncing as I find it too slow. Uploading a zip and unpacking it on the server goes way faster.

@horst haven't used J* in a while, but perhaps akeeba: https://extensions.joomla.org/extensions/extension/access-a-security/site-security/akeeba-backup/ could be installed and then you can run a backup?

Or this one: https://github.com/LostKobrakai/Paginator

I think this Gist by @Soma may be of some help.

This sounds familiar: https://www.magnolia-cms.com/blogs/christopher-zimmermann/detail~&hybrid-headless-cms~.html.

Thanks everyone for your input, you've definitely given me some other ideas on how I could approach my particular need for now. Especially happy to discover Connect Page Fields!

Have you tried upgrading one of the working sites to 3.0.83 and tried unzipping, just to be 100% sure it is 3.0.83 that is causing it?

Oh, and actually... you're not "hiding" the login URL with that. You're just making it harder to guess. You would need to add some .htaccess rules to login first via basicauth, adding another layer of security.

in the install screens, you have the choice of changing the default backend URL to something else. If you missed that step, you can always alter it later

Contact the hosting company, let the site owner identify him self, and the hosting company will email the cpanel credentials with a new password.

The new Monitor Audio website is a ground up build featuring a completely custom front end design and back end Processwire build. Modules in use include Multi Language, ProCache, Blog, FormBuilder, Instagram and ProFields. The site has a large product catalogue, dealer finder and is in multiple languages. However, one of the main objectives for the project was to deliver a platform that could be easily edited and expanded as needs grow. The client team were involved at every stage. As developers we went a long way to make sure everything was editable. Other features include: IP controlled contact form with multiple email destinations based on enquiry type Product registration form with multi-product registration from a select group of products Company timeline with year filter all based on the blog platform Dealer finder with three dealer types and in multiple countries Newsletter signup with multiple signup opportunities (sign up box and other forms) FAQ section File downloads for products from internally (CMS) uploaded files or external file links There are also several other expansions and features planned. As always we'd love to hear your feedback on the site https://www.monitoraudio.com/

https://semver.org/ Quotes: "... Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. ... How should I deal with revisions in the 0.y.z initial development phase? The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release. How do I know when to release 1.0.0? If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0. ..."

PulsewayPush Send "push" from ProcessWire to Pulseway. Description PulsewayPush simply send a push to a Pulseway instance. If you are using this module, you probably installed Pulseway on your mobile device: you will receive notification on your mobile. To get more information about Pulseway, please visit their website. Note They have a free plan which include 10 notifications (push) each day. Usage Install the PulsewayPush module. Then call the module where you like in your module/template code : <?php $modules->get("PulsewayPush")->push("The title", "The notification message.", "elevated"); ?> Hookable function ___push() ___notify() (the two function do the same thing) Download Github: https://github.com/flydev-fr/PulsewayPush Modules Directory: https://modules.processwire.com/modules/pulseway-push/ Examples of use case I needed for our work a system which send notification to mobile device in case of a client request immediate support. Pulseway was choosen because it is already used to monitor our infrastructure. An idea, you could use the free plan to monitor your blog or website regarding the number of failed logins attempts (hooking Login/Register?), the automated tool then block the attacker's IP with firewall rules and send you a notification. - - - 2017-11-22: added the module to the modules directory

It depends on where in the sort order you want the special characters to go. Without doing anything special PHP would sort special characters after ASCII characters, so for instance that would place "Čavlović" after "Zola". If that is what you want (and I doubt that it is) it seems that you can achieve this kind of sort by using the "useSortsAfter" option for PageFinder: $authors = $pages->find("template=author, sort=title", ['useSortsAfter' => true]); BTW, it's far from clear to me what the "useSortsAfter" option does exactly. But I don't think that is what you want anyway. To get a language-aware sort I think you would have to use something like PHP's Collator class - others may know better but I don't think PW has anything built in for this. So here is something that might work, but it would mean you must get all your authors in one $pages->find() - no pagination in other words: // Find the author pages $authors = $pages->find("template=author"); // Get an array where key is author page ID and value is author page title $titles = $authors->explode('title', ['key' => 'id']); // New Collator instance $collator = new \Collator('hr_HR'); // Croatian locale // Apply language-aware sort $collator->asort($titles); // Apply custom sort property to author pages $i = 1; foreach($titles as $id => $title) { $author = $authors->get("id=$id"); $author->custom_sort = $i; $i++; } // Sort authors by custom sort property $authors->sort('custom_sort'); // Now loop over $authors and output markup

The UIkit theme is looking lovely, but does anyone else think it goes a little too far in terms of padding? On my 27" monitor this interface looks quite large. On something like a 13" laptop you would not get much interface on the screen it would require a lot of scrolling. I love clean whitespace as much as the next person, but there is more than just aesthetics to consider. The admin interface is something that as developers we are going to spend a significant amount of time using. The extra scrolling and mouse movement that a widely-spaced interface requires is something to consider. Definitely not wanting a cramped, crowded interface but I think there is scope to be more efficient here, particularly in the vertical padding. In designing a utilitarian interface like this I would be inclined to follow a process of starting with no padding and then adding padding to elements by eye until it feels right.

Challenge accepted

The inputfield could be approached a similar way to Profields Table, which does support large amounts of data through limiting and pagination. It was the introduction of pagination within Table that prompted my GitHub request. But although an inputfield solution is important it is the API side that is of greater importance. Currently you cannot do anything with the value of a Page Reference field without loading all the pages into memory. So if you have a Page Reference field with 2000 items and you do... $item = $page->my_page_reference->first(); ...or... $item = $page->my_page_reference->findOne("name=foo"); ...then boom, you have 2000 pages loaded to memory. It's not like $pages->find() or $page->children() where you can be selective or limit what is loaded. Compare with $page->children(): parent-child is one kind of basic relationship between pages. Page Reference is the other kind of basic relationship between pages. Both of these relationships should be able to scale up, but currently only parent-child does. This discussion probably warrants it's own topic.

mhm, interesting ok, thousands of likes in one pagefield would not be possible. but what about a solution like this in such cases? should'nt it be possible to handle thousands of likes that way? it would be easy to store likes (or any other datatype) via the api and it would be easy to retrieve them. it would also be possible to show them in a paginated way with a runtime markup field and a lister (i guess). or (one day) maybe even with my datatables module (if anyone wants to join me on this project it would be appreciated)... dont get me wrong. i don't want to disagree about this, but i don't really get an idea of how a page reference with thousands of pages could look like. we also have the profields table that creates a database table with desired columns. only the interface for editing lacks support for large data. maybe the problem is just to have a proper way of presenting a large amount of pages inside the page editor (inside a field)? maybe my datatables would fill that gap? i'm using it all around in my projects, so i think there is a need for it. and i think it would be a great addition to processwire. do you agree or are you talking about something different?

An example would be if you want to use a Page Reference field to store "likes", where each user that has liked a page is added to the field. For a large site with thousands of users this becomes a problem. There would be plenty of other examples for sites with very large numbers of pages. Pages (in the broad sense of being some grouped data) are of course central to the PW philosophy. And Page Reference fields are the primary way to make connections between pages. So it's important that this be able to scale up for PW to be seen as a credible candidate for large projects.

hm.. ok i get the point when we are talking about the pagefield in general i agree that it can be limited at some point. i connected it to my datatables module to get a filterable, paginated list of selectable options: but in this case i'm only browsing many pages... i've never had the need to reference a lot of pages in a pagefield. can you give me some examples when you needed this @Robin S ?

preview of upcoming version with some new features: 1) upcoming version lets you place the prev/next links either in the tabs area or in the breadcrumbs (so far only on UiKit): so they look like this (using native UiKit classes): the labels go away for smaller screens: also, supports wrap-around pagination for first and last items: Overall i like the pagination up there in the right of the breadcrumbs, better than down in the tabs; This is only possible currently on UiKit theme, because the breadcrumbs are hookable; thanks to @tpr for the idea of the wraparound pagination, and the idea of moving the links out of tabs; The new version of AOS also has an option for page navigation and is a great alternative to using this module. this implementation is different in that it is using a hook and changing the markup, rather than adding the links by javascript; also this implementation does allow you to selectively show prev/next pagination based on the template, and the placement of the links it static, in the upper right, whereas the AOS version would move around next to the title. Also this version tooltips the titles of the linked pages. Edit: The links can now also be moved on Reno Theme:

Aha! Solved it, so I'm going to answer my own question in case someone else runs into this. The PHP must be compiled with the option ZIP to *really* have it "built-in". In the case of this OpenSUSE build, it is not, and must instead be installed using PECL. Initially the PECL install didn't seem to work, eg. `sudo pecl install zip`, until I realized that it needed the path too `sudo pecl install pecl/zip`, but then it worked.