horst

Added another little tool to the box that I sometimes use to detect best breakpoints for mediaqueries. A little Javascriptbox that displays the dimensions of body and a configurable custom container (by ID). What dimensions are shown, offsetWidth, ClientWidth, ScrollWidth, is dynamically configurable in the Top of the JSbox: To enable / disable it, select or drop the button in the config page, and, optionally, type in the id of a custom container.

Have seen that it was mentioned in last ProcessWire Weekly. (sighh, have hurried up with it) I have tested it with PW versions 2.3, 2.4, 2.5, 2.6, 2.7 and with PHP 5.3 and 5.4. It works good from PW 2.4+ up! With PW 2.3, the Javascript Color Picker doesn't function. But 2.3 is really old and if someone has maintained a site until now without ALIF, he will do it fine in future too. Only thing I want to know is: in wich PW version was "showIf" introduced to show / hide Inputfields in the admin? Would be nice if someone can point me to that. So, it is ready for the masses now!

@bora: with the WireMailSmtp you can use one To and the rest in a CC field. But you also can have a look to the wiremail core class and how you can extend it, and build a small extension that does what you want. EDIT: btw, thats a friendly looking new avatar, you have!

It's now on Github: https://github.com/horst-n/AdminLinksInFrontend After aproval in the modules directory, I will update the post here. Please, re-read the first post. It is updated with the release announcement and a more detailed explanation of all features.

You can use escaped doublequotes in either of the versions in your code, than it should work in PW 2.7 too: echo "More info on <a href=\"{$page->bfd_url_wiki}\" target='new'><b>Wikipedia</b></a>"; change href='...' to href=\"...\" in your template code, than it will work in every situation, regardles if you have escaped or unescaped single quotes in your URLs.

Sorry, but I really cannot follow what you are asking for. As I could understand from reading here, there was a change in PW, related to security, to not support single and double quotes in URLs per default anymore, as it was done in the past. That's a good thing, I think. And there is an option to (re)activate the old behaviour, for those, who need it. Conclusion: new behaviour + old behaviour ? what more do you need ? or what is the part that I do not understand here ? Also please refer to the according RFC 3986, where is described which characters are allowed to be present unescaped in an URL. Quotes and doublequotes are not in, or I may have overlooked it? Also the example you have posted is wrong coded and cannot have worked before too: You cannot wrap single quotes around an URL if the URL itself contains (unescaped) single quotes! Please, first fix your syntax and maybe, second, try to use more RFC conform URLs. (I know that browsers also work with malformed URLs, but since you now know that this is malformed, you shouldn't use it anymore).

I know this site too. In the past it has loadded "normally" fast. There must have definetly something changed, ServerSoftware or SiteCode. The initial request can take up to 10 seconds. Here is the culprit. Do the server provides PHP as included Apache-Module, or as fast-cgi?

Can you 100% ensure that you are not fetching ProCache files?? You can go the hard way and comment out the complete ProCache section in htaccess, rename the ProCache root directories manually, additionally to (only) disabling PC.

ALIF - Admin Links In Frontend EDIT: latest version update with PHP 8 fixes on 05. Nov 2023 (!) The version now is 1.1.9 (!) This module combines some of the admin links that we want to use on the frontpages sometimes. It is a comfortable and easy way to do so. After you have installed and configured the module, you can inject the links into the frontpage with code like this in a template file: echo $modules->isInstalled('AdminLinksInFrontend') ? $modules->get('AdminLinksInFrontend')->render() : ''; . Credits: The comfortable Javascript Color Picker in the Configpage comes from Jan Odvarko (http://jscolor.com). Many thanks for this! * Toolbar The toolbar can be positioned by css values for top/bottom and left/right. It can expand in vertical or horizontal direction. The buttons are links to the PW admin, for logout, or for editing the page in admin, or informational ones. All settings, including the colors, can be defined in the modules config page. This is available for all PW versions from PW 2.3 up to now. Depending on how you configure this part, it can be used for authors and editors too, maybe. * Import / Export Settings It has the possibility to export and import its settings via two textarea fields. When importing settings, you get a second screen where you can select which settings you want to import. * One-click User Account Switcher For PW versions 2.6.8+, there is one really nice function available, that I use when developing / testing sites with different user / roles. A fast User-Account-Switcher that lets you view the same page from different user accounts with only one click. To enter this mode, you need to login as a superuser one time, and the feature needs to be enabled in the module of course. After that, you can log out, login with different user roles, etc. At least the toolbar buttons for the User-Account-Switcher will stay visible for you. This is session based. There is also an extra button with a trash can and the text "Session", that helps you to leave this mode once you are finished. As you can see in the screenshot, after clicking "guest", I was logged out, but a regular login button, a warning for debug mode and my three defined buttons for user accounts are available. When clicking another user button I login with this account. Very handy. ATTENTION! The use of the One-click User Account Switcher is mainly intended for dev sites, not for public sites! You should be aware that there is a huge security risc when using this feature on public reachable sites! We completly leave ProcessWires comfort zone in regard of security, - and the only thing between your site and potentially hackattacks is this module. (Oh mom, - what have I done?) PW 2.6.8+ has a comfortable function for admin tasks, that let us log into different user accounts via API without using passwords. This module uses this function! All data that is needed during a User Account Switcher session is stored in the session data on the server. So, if someone steel your session cookie, there is potentially risc that he can login as a superuser, depending of the user account buttons you have in your admin links collection! To prevent SessionHijacking, the module can be bound to a single IP address, it uses a fingerprint depending of IP(s) and UserAgent string. And you need to define a max time to live in minutes between 2 and 60, a User Account Switcher session may run. A User Account Switcher session only can be initialized by a Superuser who also explicitly has set a permission called 'alif-user-account-switcher', what is defined by the module, when installing it. So, the prefered way to use this module is, to enable and use the User Account Switcher while the site is unpublic, and before it goes public, remove the permission from the superuser role. This way, you can use its menu function, but not the UAS anymore. On a sidenote, for those rare cases where multiple superusers simultaneous developing on a site and want to use the ALIF, but the UAS should be used only by one, you can leave the 'alif-user-account-switcher' permission removed from the superuser role, but need to assign the role 'alif-superuser' to the single user account. This way, only that single superuser has the permission for UAS, whereas all other superusers doesn't have it. . . * The Configpage * Online demo I have pasted it into this old site and enabled it to be present every time (when the site is in demo mode only!). So, it is an earlier state, but the switcher is functional there: http://pwlaf.biriba.de/dbinfo/ * Download From our modules directory or from github repo

I would upgrade not all at once (PHP, MySQL, PW) and not in such big steps (PHP 5.3 => PHP 7). But you don't need to update PW in small steps. I would (and have done by myself several times) let the site (copy?) on a server with PHP 5.3 and only change the wire folder with 2.7 stable and also the 2.7 index.php and the 2.7 htaccess file. Before that, backup the DB!! After that, goto the admin and login. If there are errors, just reload the page 3-5 times and go to modules and do a refresh. After that, everything core related should be up to date. But you may run into some issues with third party modules or with body fields in your site. AFAIR, PW 2.3 uses not the CKEditor. Your body fields, if any, will throw errors or warnings. If you have those fields, I would do one intermediate step: before upgrading, I would load ckeditor as site module into the PW 2.3 installation. Then bind all textarea fields to it, instead to the older editor. Do another DB backup! and then go ahead and change wire to PW 2.7. After your site is running properly on PW 2.7, PHP 5.3 and the older MySQL, change the PHP version and the mysql.

I have used it only one times. If it is of any help, I can paste in some code snippets here from that site. But it isn't an infinite only solution, it is bundled together with masonry. http://joerg-hempel.com/archiv/ JS parts: // JS in every page that uses infinite scrolling <script type='text/javascript'> var gLoaded = 0; var gMaxPages = 12; var gTriggerPageThreshold = 100; var gPaginationHistory = false; // switch on / off URI updating for pages: example.com/path/page2 | /page3 | page4 var gContainer = '#albums'; var gItemSelector = 'article.album'; var gColumnWidth = 228; // 48 var gGutter = 12; // 12 $(document).ready(function() { // make it visible if JS is supported $('div.ias_msg').css('display','block'); starteMasonry(); starteIAS(); }); </script> in an external JS file I have the functions for Masonry and IAS: function starteIAS() { jQuery.ias({ container : gContainer, item : gItemSelector, pagination : '.pagination', next : 'a.next-album', loader : "<img src='/site/templates/styles/images/loader.gif' />", thresholdMargin : -9, triggerPageThreshold : gTriggerPageThreshold, history : gPaginationHistory, noneleft : "<div class='ias_msg noneleft'><p>no more items available</p></div>", onLoadItems : function(items) { // HNLOG console.log('IAS onLoadItems (' + gTriggerPageThreshold + ')'); var newElems = $(items).show().css({ opacity:0 }); newElems.imagesLoaded(function(){ $('#albums').masonry('appended', newElems); newElems.animate({ opacity:1 }); }); $('#albums').masonry('reloadItems'); return true; } }); } function starteMasonry() { var items = $(gContainer + ' ' + gItemSelector).show().css({opacity:0}); $(gContainer).masonry({ itemSelector : gItemSelector, isOriginLeft : true, isOriginTop : true, columnWidth : gColumnWidth, gutter : gGutter, isAnimated : true, // !Modernizr.csstransitions isFitWidth : true }); items.animate({opacity:1}); } The PHP looks like: // calculate current amounts $limit = 100; $max = $pages->find("$pSelector,limit=2")->getTotal(); $cur = $input->pageNum; $next = ($cur * $limit) < $max ? $cur + 1 : 1; $prev = $cur > 1 ? $cur - 1 : 0; $start = $cur < 2 ? '0' : strval($limit * ($cur -1)); // echo prev-next links for pagination (only next is required, prev isn't used !!) $pagination = "<div style='display:none' class='pagination'>"; // hide it !! //if($prev > 0) $pagination .= " <a href='{$archivURL}page{$prev}'>prev</a> |"; if($next > 1) { if(isset($nextPageUrl)) { $pagination .= " <a class='next-album' href='{$nextPageUrl}page{$next}'>next</a> "; } else { $pagination .= " <a class='next-album' href='{$archivURL}page{$next}'>next</a> "; } } $pagination .= "</div>\n"; echo $pagination; // Hinweis zum scrollen echo "<div class='ias_msg scrolldown".($cur)."'><p>scroll down to get more items</p></div>"; // get PageArray $albums = $pages->find("$pSelector, limit=$limit, start=$start, sort=sort"); // output albums with thumbnail and infos foreach($albums as $album) { // ... render items } Using IAS, you even don't need to check for ajax request or not. just send the whole page, with header and body. The script knows the selectors and pick up the needed content and add it to the dom, after the last renderd from previuos request. Easy!

You may use one of those ready to use JS Libraries for Infinite Scrolling you can found on the net. One that I know and have used myself is IAS. In PW you must use pagination as you explained above, also have to render the NEXT button, but with display:none in CSS to make it invisible. The JS-Script will pick it up and loads the next portion when the user scrolls down.

For me, I can click on the logo, I can click on Admin in the bread crumb and I can doubleclick on Pages to move directly to the Tree.

Hhm, this is right, in general. - But, if you use FTP from within a php script, you can use it for deploying. To execute scripts, you can A) upload individual scripts to the server (via FTP). and after upload, you can trigger the execution via HTTP. Accessing DBs also is easy. I have used php for a long time for syncing files on live and local servers. Scanning local project directory and collect last-modified + crc32 checksums, than do the same on the live server. - Hhm, I found an old script, - tested it and - surprise - it is still running! (I will upload some screenshots.) It originally was created in that times when webdev often was writing and deploying static html files, or maybe some php files but without a CMS, etc. (around 1998/99, for me) So, this is only in the context of historical interest.

Another hint is, if you have already unsorted images in your pages, to use this very nice snippet from @lostkobrakai (in ready.php): https://processwire.com/talk/topic/11069-sorting-images-in-backend/

You also can enable zip upload for imagefields! That has the nice side efect that the images are also alphabetically sorted. (What they are most often not when asynchron single uploading)

In witch scope does dompdf use them? (class internal? global?) Also if your module does its work on the admin side, it can be that you use autoload with it? If yes, it is called very early. You should thouroughly check if the $user and $page from dompdf and pw does not interfere.

It is a certificate that doesn't match. This has not directly to do with the module but with the server (certificate). An expected IP (52.19.6.114) doesn't match. The IP (52.19.6.114) is mapped to the hostname "ec2-52-19-6-114.eu-west-1.compute.amazonaws.com" and the hostname (email-smtp.eu-west-1.amazonaws.com) resolves to IP "52.30.192.168". So this is something that you need to sort out with the hosting company.

additionally you could/should set $config->debug = true; in the site/config.php. So, maybe it isn't of help in this case.

Hi, it is just an example. I use module SPEX, that provides delayed output and a lot more. With it I call the files like this: $spex->addScript('scripts/jquery.min.js'); $spex->addScript($myMainJSfile); $spex->addStyle('styles/main.less'); It is similar to the regular use of $config->scripts->add( $config->urls->templates . $myMainJSfile );

Hi @driedstr and welcome to the forums. If you are sure it is this line when start building $config, it can be worth to have a look what you put into your site/config.php ?? Have you put customized stuff / settings into it?

Hi @totoff, it depends on what tasks I want apply to a site. If it only rely on template files, css and js files, I switch from regular to dev-files. Means, I use a little abstraction layer for including my files like this: $myMainJSfile = "scripts/main.js"; $myMainCSSfile = "styles/main.css"; When working on a live site, I use something like this: if($user->isSuperuser()) { $config->debug = true; $myMainJSfile = "scripts/main.dev.js"; $myMainCSSfile = "styles/main.dev.css"; } else { $myMainJSfile = "scripts/main.js"; $myMainCSSfile = "styles/main.css"; } When working on templatefiles, I put in the top of the template file a few lines of code: if($user->isSuperuser()) { include("./nameOfMyTemplateFile.dev.php"); return; } This switches to a dev version of the template file and returns directly after including it. (The code of the original isn't executed). This is a basic description. Depending on how you have organized your site, there is a lot room for improvements, go into depth, make it a more granular system. But you get the idea. If I need to alter the DB too, I use a separate site/config.dev.php too. YOu can read about it here, scroll down to the end: "Maintaining a separate development configuration file". (I duplicate the DB to a dev-version and connect to it for development)

@alan: WOW! What a great find. You are right. I have checked this and yes, on the site I thought it would working together, it also bypasses SMTP as you described it. @justb3a: please can you fix this with one of the next releases?

I use it on one site with wiremailSMTP and it works. But I haven't used it together with Mandrill. I think you use a recent or latest version of SCF? (earlier version hasn't supported wiremail()) You may check in the headers of your emails for the User-Agent, e.g. ProcessWire/WireMail or ProcessWire/WireMailSMTP or ...

It uses it out of the box, mean: you haven't to do anything in regard of SCF. SCF uses wiremail(), - and if you have installed and setup wiremailSMTP, it is used instead of the basic wiremail, which uses the PHP mail function.