Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 04/27/2019 in all areas

  1. @ryan, may I point you to a WebP pull request? https://github.com/processwire/processwire/pull/141 And a ".htaccess only solution" for site wide webp support: https://processwire.com/talk/topic/14236-webp-support/page/2/?tab=comments#comment-184669 ?
    7 points
  2. Just a brief update today. I’m going to give it another week before bumping the core version, as I don’t think there’s enough changes yet to warrant a version bump. For whatever reason, several of my clients have needed integration with Stripe (payments) over the last few weeks. I’d not worked with it before the last month or so, but now all of the sudden am working with it a lot, because that's what my clients have asked for. I’ve found myself working on four different Stripe integrations on existing PW sites, both Stripe Elements and Stripe Checkout. None of these are for sites that have an actual “store” where they would need a cart, but rather just “pay for your reservation”, “buy this book”, “buy this song”, and “make a donation of $10”, “make a recurring donation”, type things. After doing a few of these, I thought it would make a lot of sense to have this built into FormBuilder, which would save us time on this stuff. So this week I built Stripe support into FormBuilder (using the Stripe Elements API). It’s already fully functional, so I will be releasing a new version of FormBuilder with this capability quite soon. To add a Stripe payment input to your form you just add a new field of type “Stripe payment for FormBuilder”, and then it asks you for some info about it (like amount to charge) and then your form works as a payment processor. Stripe has a clever way of making this all work, so that the user never leaves your site, but your site (and FormBuilder) never sees credit card numbers or anything like that, so it’s secure and you don’t have to consider things like PCI compliance. I've also got some other unrelated updates for FormBuilder that I'll be covering soon as well. Have a great weekend!
    5 points
  3. Confession bear meme on tests: I'm a virgin. Never implemented any of them, mostly because I work alone for many years now. But found this cool project today, called Cypress. This is the easiest way to test a website or app I've found. Check their intro video out: https://docs.cypress.io/guides/getting-started/writing-your-first-test.html Note: I recommend this Chrome extension to speed up videos: https://github.com/igrigorik/videospeed as the narration of this video is kinda slow. ?
    4 points
  4. Frontend built in UIkit 3. Backend is a modified version of what I did for HealthCARE Express. I am using the top level pages to hold information only, so no design rows as children. Children are always sub pages. The page builder area is under a settings page that has children for things like the navigation menus, and themes. (The themes hold the page layouts, color schemes and uikit and theme components.) Here is a video showing adding an intro section to a basic page. (Basic page has an inner page heading row already added.) . Instead of adding a text item, I could have added a code item and echoed text tied to the basic page. I may also make a hook for auto creating the layout page to save that step, and add a link on the front end for adding new rows without needing to visit the backend settings area. I put menus under settings so you can design the top menus, main menu, and footer column menus from one spot, and every widget that reads them gets set at one time. You can also control if they open in the same or new windows, and add off site links this way. I just feel like depending on only hidden and non hidden root pages is not enough. Also, an incoming theme can default to reading a menu named a certain way. Menus are primarily set via selector, so you do not need to edit it them every time you add a service for example, like if you wanted to have a service menu in wordpress. So if I do a page template for a Service, there can still be a rich text box and image field for that service attached to the page template, so there is no way for someone to mess up the design just to edit, and to reduce confusion, but if you want to use the page builder to add rows, you can dig into that settings page and edit the rows for the page. I also have front end editing turned on so you can double click almost anything to edit, and added a small drop down at the top right of the page that loops through all rows on your page so you have a shortcut to edit just that row from the backend. The page builder rows are matched by path. ie. /about/ would match /settings/themes/selectedtheme/bypage/about/ and might match /settings/themes/selectedtheme/bytemplate/basic-page/ also, if the about page was a basic page template. Everything will match the sitewide folder. This type of thing lets you do things like add a call to action on a group of pages by adding that row to the template instead of the page. Or add a css file or javascript file to a group or sitewide. The layouts template holds the layout types, like per page or per template, and layout types can have children like sections, containers, grids, cells, images, text, accordions, php or html code, etc. I have also played with doing a page group layout type so you can group a few pages together and add a row or code snippet to those as well. This output method does not require php eval. I actually just start an output buffer and include. That gets added to a snippet array variable that I can sort and edit until the very end when it is time to output. The first level in the array is 8 slots that works as placeholders, and then each of those 8 slots holds the rows or code snippets for that placeholder. ie. before html, head, body-top, body-header, body-main, body-footer, body-bottom, after html are the default placements code can target. The second level also has weights. In addition to targeting a placeholder, a section will also have a priority drop down of highest, high, medium, low, lowest. That way a bottom call to action can be tied to the body-main spot as low priority, and no matter if it is added to the template, page group, page or sitewide, it will always sink to the bottom. Plugins used: Inputfield Ace Extended, MarkInPageTree, Breadcrumb Dropdowns, Prev/Next Tabs (for switch from row to row), Hanna Code The page builder has almost all of UIkit added so you can add a grid to a section and set the child width by drop downs, or you can use drop downs to set them on the child cell pages individually. The cell pages would allow you to add heading, text, images, accordions, etc. If you add a text item to a cell for example, the first tab is content for the rich text editor, and the second tab is design for things like text alignment per device. (So you can say center on mobile or left align on desktop without writing any code!) . The advanced tab holds an id over ride, extra classes box, and a javascript and css box that will minify on page save and be included into your website. This allows any item to add advanced css or js in a portable way. I will attach some screenshots! https://www.medpracticesuccess.com/
    3 points
  5. Maybe this helps https://processwire.com/docs/security/file-permissions/
    2 points
  6. $results = $pages->find('template=repeater_your_repeater_field, limit=10'); $content = $results->each(function($item) { $out = "<h2>{$item->title}</h2>"; $out .= "<p>{$item->title}</p>"; return $out; }); $pagination = $results->renderPager(); d($content); d($pagination);
    2 points
  7. Another update to the PageImage class, comes in handy during the webp work. But it is not only useful for WebP copies, but for everything in regards of experimenting and debugging with images. I added a new method: ->getDebugInfo($options). See examples here: https://biriba.de/pw_pop3/pw_pageimage_getdebuginfo/
    2 points
  8. Hi @Tom. the new code is online in my test branch. And following is a test with also the .htaccess solution installed. My template code: <?php $image1 = $page->images->first->size(100, 100, $options); ?> <img src="<?=$image1->url?>" alt="<?=$image1->alt?>" /> <img src="<?=$image1->url?>?skiprewrite" alt="<?=$image1->alt?>" /> <?php $image2 = $page->images->first->size(100, 100, $options); ?> <img src="<?=$image2->url?>" alt="<?=$image2->alt?>" /> <img src="<?=$image2->url?>?skiprewrite" alt="<?=$image2->alt?>" /> The quality settings for the regular variation is set to 10, it is created first in the image engines. The webpQuality was set to 100, and it is created after the regular variation. The following screen first shows the webp copy and due to the "?skiprewrite" GET varname, it shows the (distorted) jpegs at second place. Once with GD and once with IMagick: I really love the .htaccess only solution! With this, you simply can update any existing site by upgrade to the new PW core that include the webp support and running a maintenance script over all image variations to create the webp copies. After that you are done! ?
    2 points
  9. I have background color, gradient and background image groups on design templates like sections. (This website used for page headings and footers also.) The entire website was designed within processwire. I only have one physical template file and everything runs through that. (It pulls the sitewide, template, and page rows designed from backend. Supports parent and child themes.)
    2 points
  10. You are free to test it with the latest API version before changing it. As for the login settings, you will first have to add product "Facebook Login".
    1 point
  11. Unless of course, you get your German mate to set up coder in a server running in his lounge room (he did it in like under 10mins) and first impressions are pretty impressive. I'm using Coder from Australia connecting to a home server in Germany, and the limited experience I have is pretty good. Latency is expected but better than I thought. I haven't installed extensions that I normally use and I should sftp across a project I'm working on to fully test it out. But just opening/editing files seem pretty good so far. A bit busy at the moment, but when I get a chance to test it out in anger, will let you know.
    1 point
  12. FYI: https://uppy.io/blog/ "Today, after 3 years of development, we are launching version 1.0 of Uppy, our file uploader for web browsers." "Saves battery and data plan by letting users pick files from Webcam, Dropbox, Google Drive and Instagram, while letting servers do the heavy lifting via Companion"
    1 point
  13. For mac apps I can also recommend https://paw.cloud/.
    1 point
  14. I've not used it much and I don't really like the api much (seems very verbose compare to other tools), but it's integration makes up for very much. It's possible the best testing tool I've seen to date in terms of visualizing what's happening but also having an interface to visualize what's happening as the testsuite is run.
    1 point
  15. I have played with a .htaccess only solution to serve WEBP instead of JPEGs or PNGs. This way you can - leave your existing template markup untouched, and the apache_rewrite will - detect if the browser supports WEBP - if a WEBP copy is available for a JPEG or PNG image. Locally it's working out nicely! ? This markup automatically serves a WEBP copy to all browsers that support it: $options = ['webpAdd'=>true, 'webpQuality'=>90]; $image = $page->images->first()->size(300, 300, $options); // this will create a 300x300 Thumb for JPEGs and PNGs with an additional WEBP copy ?> <img src="<?=$image->src?>" alt="<?=$image->alt?>" /> <!-- this will serve the WEBP image to all Browsers that supports it, and the JPEG/PNG to other browsers --> AddType image/webp .webp <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 ### Redirect regular PW JPEGs and PNGs to their WEBP image copies, ### if available and if the Browser supports WEBP: ## Does Browser accept WEBP images? RewriteCond %{HTTP_ACCEPT} image/webp ## Is it an existing file? RewriteCond %{REQUEST_FILENAME} -f ## Does a WEBP copy exist for it? RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.webp -f ## With an added GET var or GET value of skiprewrite we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch '*skiprewrite*'" ## With an added GET var or GET value from the PW Page Editor, we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch 'nc=*'" ## Is it a regular PW JPEG or PNG image, stored under site/assets/files? RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.(jpe?g|png)(.*)$ /$1$2$3/$4.webp [L] </IfModule> Adding a GET var or GET value with the string "skiprewrite" added to an image bypasses serving the WEBP copy in favour for the original variation. (Maybe useful for debug purposes!)
    1 point
  16. @dragan Maybe it has to do with permissions, see below. Ok so I have dug deep and determined why it isn't working. The $page->trashable() method is added by PagePermissions.module as a hook. The method PagePermissions::trashable first calls $this->deleteable(), which returns false for the current page (so far expected and documented behaviour). However, the $this->wire('permissions')->has('page-edit-trash-created') check in this line fails, since the page-edit-trash-created permission doesn't exist in a default install. Since it directly calls the permissions fuel whose has method doesn't check for superuser, and the check fails if the permission doesn't exist. If I either create the permission through the backend or replace the above check with $this->user->hasPermission('page-edit-trash-created'), it works as expected. @ryan Is this a bug or intended behaviour? Seems pretty counterintuitive that the superuser fails a permissions check on a default install (basic profile). Maybe we can replace the line in PagePermissions.module above: // current if(!$event->return && $this->wire('permissions')->has('page-edit-trash-created') && $page->editable()) { // change to if(!$event->return && $this->wire('user')->hasPermission('page-edit-trash-created') && $page->editable()) { I'd be happy to open a Github issue or pull request, but I'm not sure if this is actually the intended behaviour, so it would be nice to get a statement on this. Thanks!
    1 point
  17. Another advantage of storing the template code in the database is you can attach all php/html, js, css, and images/files, into the one page so it is completely portable. So you could import a component page into your theme folder, and everything that is needed is there. And to uninstall you just delete the one page.
    1 point
  18. I have one selector that pulls all children of the different layout type pages in one query using "or groups", and I just loop through the results. Each item will have itself for the data side but the items template file is not really used for logic or html. The magic is I load a component file for the logic and html bones. So when a child section is loaded, say an intro section, the variable is saved as $section, and I check for the existence of the section component. If there I include it, if not I make it and include it. ie. $filename = '../assets/cache/PHP/component_' . $snippet->template . '.php'; If not there you can get that templates component file and make the file like this: template=component,name=' . $snippet->template. When you edit the component via ace php text editor, you clear the cache/php/ folder. That way no extra database work is needed, it just includes the file with the proper path like processwire would a normal template file. The difference is instead of all of my template files being in processwire folder and needing to be uploaded, I can sort them into folders like uikit or template, and organize them and version control them and never upload. An example of a theme component may be a page heading, php snippet, footer, header, blurbs, etc. This also has the advantage of almost never needing to sync code changes between servers in a load balanced environment. All php code is in the database and saved into cached files that can be cleared or rebuilt at any time if a new instance spins up. I do need to sync assets like uploaded files and images though. So the section template has the fields, but the section component has the logic and html.
    1 point
  19. ClearCacheAdmin Module Since there's so many asking how to clear cache. Here comes a helper module that let's you clear caches directly from the admin menu. Additionally it has its own admin page that's a collection of the various caches available in ProcessWire in one place. See some infos and clear them. WireCache (using $cache) caches in the DB and there no way to clear it from the admin. Now you can delete the entries individually or all in one go. Supports following cache types: - Template "Page" Cache (disk file cache) - MarkupCache module (file cache) - WireCache (DB) - Other files and directories found in assets/cache/ path Wanted to do this for a long time. It was also great fun to do it and give something to the community to also learn something. For now it's on github only. Requires ProcessWire 2.6+. https://github.com/somatonic/ClearCacheAdmin
    1 point
  20. Template has to allow pagination not url segments, that two different things.
    1 point
  21. I have puzzled over this too, but I think the confusion comes from a non-standard use of the word "absolute" in relation to the URL. So ProcessPageEditLink never inserts an absolute URL in that it never includes the protocol or domain. But I think the absolute option means absolute relative to the site root. So the link URL starts with '/' as opposed to the two relative options which can give a link URL like '../some-page/'. The current behaviour is a good thing, because otherwise all links would break when the root domain changes (e.g. going from dev to live environment). But it would help if the meaning of the absolute option was clarified.
    1 point
  22. Little admin helper module: Using this module you can view all template cache settings at once. E.g. cache status, cache time (configurable). Furthermore it adds the functionality to clear the entire template cache or just the template cache for a given template. Note that this may cause a temporary delay for one or more requests while pages are re-cached. GitHub: https://github.com/justb3a/processwire-templatecacheoverview
    1 point
  23. If you're logged in you have no template cache, unless you enable it for logged in users. That's enough most of the times. There's also whitelist for POST and GET for template cache. So simply adding "nocache" to the GET field when enabling template cache would let you see non-cached version by simply adding /?nocache to a url. The only way to disable template cache via a config, the only way would be to make a hook before Page:render() and set the "allowCache" render option to false. Somewhere in an autoload module public function init() { $this->addHookBefore('Page::render', $this, 'hookRenderPage'); } Then the method to set the arguments for "allowCache" to false if config disableTemplateCache is true public function hookRenderPage($event){ if($this->config->disableTemplateCache){ $args = $event->arguments(1); $args['allowCache'] = false; $event->setArgument(1, $args); } } Now one can add to the config $config->disableTemplateCache = true;
    1 point
×
×
  • Create New...