Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/22/2023 in all areas

  1. The core version has been bumped to 3.0.233 this week. While there aren't a lot of commits, there are some major updates to the core PagesVersions module. I also thought a version bump would be helpful as there's also a new PagesVersionsPro version released which requires features only available in 3.0.233. The PagesVersions module is now pretty much finished in terms of its API and feature set. This week the ability to save and restore partial versions was added, and that was the main remaining thing. By partial versions, I mean the ability to specify what fields are included when a version is saved or restored. Though I think it's primarily useful on the restore side. So if you find you just want to restore one or more particular fields from a past version, rather than all the fields, now you can. The core PageTable field was also updated to support versions, partially anyway. It supports versioning of items already in the page table, but doesn't handle versioning of items that you might add or remove within a version. It turns out it's going to be a lot of work to do that, so I settled with just partial support for this week. As it is, if you add a new item to the PageTable while in a version, then it'll ask you if you want to import it once you edit the live version. If you delete an item, it'll be deleted from all versions. That's how it works temporarily until it fully supports versions. ProFields Table now also supports versions. But there is one case where it doesn't: paginated table fields. A future version of Table will add support for that. Until then, the PagesVersionsPro module does make it clear when a paginated table field won't be added to the version. So now all fields in ProcessWire are supported, except for certain scenarios in PageTable and Table fields. A new version of the PagesVersionsPro module was released as well, and this is posted in the PagesVersionPro support board download thread here. This module made a lot of progress this week and will continue to evolve in the coming weeks. I'll copy/paste the version 2 changelog for it below this post. This weekend or early next week I also plan to release new versions of ProFields Table and Combo. These versions facilitate versions when doing partial save or restore operations that include file or image fields in Table or Combo fields. I hope that you and your family have a wonderful Winter/Christmas/Hanukkah/Festivus holiday! Version 2 changelog for PagesVersionsPro Added the ability to select which fields are included during a restore. When doing a restore, it now detects which fields differ between "live" and "version", making it easier for you to choose which fields to restore. When editing a version the “Delete” tab in the page editor now refers to deleting the version rather than trashing the page. The “compare” option has now been improved so that it can better detect differences between the live and version page. During restore, if you “Choose which fields to restore” you now have the option to compare them individually to see what is different between live and version. Added "page-edit-versions" permission so that you can limit the capabilities of this module to specific user roles.
    8 points
  2. In this tutorial I want to show you how to set up a simple ajax-driven auto-complete search within ProcessWire. Something that looks like this: Requirements: 1. Use the Fieldtype Cache to create a search index For fast and easy search queries we will create a search index field. You can read more on this here: https://processwire.recipes/recipes/set-up-search-index-with-fieldtypecache/ First of all, go to Modules and install a Core module called FieldtypeCache. Add a new field “search_cache” and select “Cache” as it’s type. Save the field. On the Details tab choose the fields you want to make searchable. Save again. Add “search_cache” to all templates you want to include in your search results. Optional but recommended: use the “Regenerate Cache” option found from the Details tab of the field to make existing content instantly searchable. In my case i only want to search inside body and title fields, so I included those fields in the settings of the search cache field: 2. Install the Pages2JSON module We want to make ajax requests to the search template and those results should be returned in JSON format so that our java script can process the results inside the auto-complete dropdown. Therefore we make use of this module here: https://processwire.com/modules/pages2-json/ In the module settings we define what data will be included in the JSON object that is returned. Remember that this is the data that we want to display in our auto-complete dropdown. So for my case I only want the title and the url field. Now let's start: 1. Setting up the search template Set up a template file called „search“. Then create a page using this template. On most ProcessWire installations this is already the case and this template exits in the file system. This template will handle the search queries and list all the results for us and that in two ways: - you can send a search query and the search result page will list all the results (as you would expect) - you can send an ajax search query and the result page will return the results as a json object to be processed within javascript and displayed in the frontend in real-time search.php: <?php if($config->ajax) { // Return search results in JSON format $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find('search_cache%=' . $q);; // Find all pages and save as $results header("Content-type: application/json"); // Set header to JSON echo $results->toJSON(); // Output the results as JSON via the toJSON function return $this->halt(); } ?> <main> <div class="uk-container"> <?php // look for a GET variable named 'q' and sanitize it $q = $sanitizer->selectorValue($input->get->q); // did $q have anything in it? if($q) { // Find pages that match the selector $matches = $pages->find('search_cache%=' . $q); // did we find any matches? ... if($matches->count) { echo "<h2>We found $matches->count results:</h2>"; echo "<ul class='uk-list uk-list-square'>"; foreach($matches as $match) { echo "<li><a href='$match->url'>$match->title</a>"; echo "<div class='summary'>$match->summary</div></li>"; } echo "</ul>"; } else { ?> <h2>No results found.</h2> <div uk-grid class="uk-flex uk-flex-center"> <div class="uk-width-1-1 uk-width-1-2@m"> <?= $files->render('elements/_searchbox'); ?> </div> </div> <? } } else { ?> <h2>Search:</h2> <div uk-grid class="uk-flex uk-flex-center"> <div class="uk-width-1-1 uk-width-1-2@m"> <?= $files->render('elements/_searchbox'); ?> </div> </div> <? } ?> </div> </main> Explanation: This part here at the top of the template handles the requests that are send via ajax. This is the important part for later on. <?php if($config->ajax) { // Return search results in JSON format $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find('search_cache%=' . $q);; // Find all pages and save as $results header("Content-type: application/json"); // Set header to JSON echo $results->toJSON(); // Output the results as JSON via the toJSON function return $this->halt(); } ?> What this does: check if the current request is an ajax request if so, search inside the search cache field return the results in JSON format then quit processing the rest of the template (we don’t want to render any markup in that case!) Everything below this part is the normal search template logic. If you send a search request via a form somewhere on the website you want to be redirected to the result page and all the results will be listed on the page just like you would expect. 2. Make the search „work“ Create a template file called "_searchbox.php" (this file is also included in the search template code above, so adjust your paths/names accordingly). To make search requests you want to include this search form anywhere on your page. _searchbox.php: <div class="search-wrapper uk-padding uk-text-center"> <h4>Searchbox</h4> <form class="searchform uk-position-relative uk-flex" method="get" action="<?= $pages->get("template=search")->url ?>"> <input class="uk-input" id="searchInput" name="q" type="search" aria-label="Suchen" autocomplete="off" placeholder="z.B. Bagger"> <button class="uk-button uk-button-primary search-button" type="submit"> <span class="uk-visible@s">Search</span> </button> <div id="suggestions" class="uk-box-shadow-medium"> </div> </form> </div> With this simple search form you should now be able to do a basic search that leads you to a search result page. 3. Make the ajax-search „work“ Now comes the interesting part. We will add in a java script snippet into our just created _searchbox.php that sends ajax requests to the search template page while we are typing into the search intput field and it will display the results in a nice little dropdown. Feel free to adjust the code to your needs! <script> document.addEventListener("DOMContentLoaded", () => { const searchForm = document.querySelector('.searchform'); const searchUrl = searchForm.getAttribute('action'); const searchInput = document.getElementById('searchInput'); const suggestionsDiv = document.getElementById('suggestions'); let selectedSuggestionIndex = -1; // close the auto-complete container when clicked outside the element document.addEventListener('click', function(event) { if (!suggestionsDiv.contains(event.target)) { suggestionsDiv.style.display = 'none'; } }); searchInput.addEventListener('input', () => { const searchText = searchInput.value.toLowerCase(); // Immediately Invoked Function Expression (IIFE) (async () => { try { const response = await fetch(searchUrl+"?q="+searchText, { headers: { 'X-Requested-With': 'XMLHttpRequest' } }); if (response.status === 200) { const data = await response.json(); showResults(data); } else { console.log(response.status); console.log(response.statusText); } } catch (error) { console.error(error); } })(); function showResults(data) { // Show suggestions only if the input has at least two characters if (searchText.length >= 2) { const suggestionHTML = data.map(item => { // Highlight the matching characters using a <span> element with a CSS class const highlightedTitle = item.title.replace( new RegExp(searchText, 'gi'), match => `<span class="highlight">${match}</span>` ); return `<li class="suggestion"><a href="${item.url}">${highlightedTitle}</a></li>`; }).join(''); // Array to string conversion suggestionsDiv.innerHTML = ''; // Clear the suggestions if input length is less than two characters // create list and append search results const suggestionList = document.createElement("ul"); suggestionList.classList.add('suggestion-list', 'uk-list'); suggestionList.innerHTML = suggestionHTML; suggestionsDiv.appendChild(suggestionList); selectedSuggestionIndex = -1; // show the results suggestionsDiv.style.display = "block"; } else { suggestionsDiv.innerHTML = ''; // Clear the suggestions if input length is less than two characters } } }); // Event listener for arrow key presses searchInput.addEventListener("keydown", function (event) { const suggestions = document.querySelectorAll(".suggestion"); if (event.key === "ArrowDown") { event.preventDefault(); selectedSuggestionIndex = Math.min( selectedSuggestionIndex + 1, suggestions.length - 1 ); } else if (event.key === "ArrowUp") { event.preventDefault(); selectedSuggestionIndex = Math.max(selectedSuggestionIndex - 1, -1); } else if (event.key === "Enter") { event.preventDefault(); if (selectedSuggestionIndex === -1) { searchForm.submit(); } else { window.location = suggestions[selectedSuggestionIndex].querySelector('a').href; } } // Highlight the selected suggestion suggestions.forEach((suggestion, index) => { suggestion.classList.toggle( "selected", index === selectedSuggestionIndex ); }); }); }); </script> Keep in mind that you need some CSS styes to make it look good and actually work. These are my styles(in LESS format) but feel free to write you own stylesheet for this. search.less: .search-wrapper { position: relative; background: @secondary-blue; h4 { color: @primary-blue; } .highlight { color: @primary-red; } } #suggestions { display: none; position: absolute; top: 100%; left: 0; right: 0; z-index: 10; background: @white; .suggestion-list { margin: 0; li { transition: background-color 150ms ease-in-out; a { padding: 10px; display: block; text-align: left; &:hover, &:focus, &:active { text-decoration: none; } } &:hover, &:focus, &:active, &.selected { background: @secondary-blue; } } li + li { border-top: 1px solid @secondary-blue; } } } That's it! Again feel free to adjust all of the code to your needs. If you have any suggestions how to achieve things a bit easier just let me know.
    2 points
  3. If you are into Docker, you can use my template to create your own local installation (although intended for development). It maps the site directory outside of the container for development. But you should easily be able to just upload your zip to the container and extract it over whatever is there already. For the DB, you can put the dump into the data folder and name it 'database.sql' and then run the 'dbrestore' script (for this, the composition must be running). poljpocket/processwire-docker: Docker installation of ProcessWire for local development (github.com)
    2 points
  4. PAGEGRID 2 is out now! ? The new version contains several bug fixes and adds exciting new features. It's also more flexible and easier to use. Check out the new website ? and click the edit button ✏️ to see for yourself. With this update, PAGEGRID becomes a very flexible no-code editor that still gives developers the power and control they need. Easily modify existing block templates or create your own with your favorite code editor and ProcessWire's powerful API. Use PAGEGRID to build whole websites, connect PAGEGRID to regular ProcessWire templates/pages or use PAGEGRID only as a "body" field. PAGEGRID 2 uses as many native features from ProcessWire as possible (everything is a page). NEW Reusable Symbols Turn nav bars, footers, or any combination of items into symbols that you can reuse wherever you need them. (Symbols are pages) Animations Add powerful multi-step CSS animations with a few clicks. Use interactions like scroll, mouseover, inview, loading or click to trigger them. Reuse them throughout your website. (Animations are pages) Blueprints Blueprints can be used to automatically populate empty pages with a predefined layout. They are useful if you want website editors to start from a base design when they create new pages. (Blueprints are pages) DOM Navigator The dom navigator makes it possible to select any markup on the page through PAGEGRID's style panel. It gives you full control over your site's appearance. Style regular templates Make CSS edits to any template inside processwire just by adding the PAGEGRID field to it (works with any markup). VW and VH units Almost all style inputs now support PX, %, VH and WV units. Updated Google Fonts The fonts list has been updated to include the latest fonts and material icons. Datalist Block (PageGridBlocks module) The new datalist block renders a link list of pages that you can define. It can render a title, thumbnail, video, or text per page. This can be useful for rendering a grid of your latest portfolio projects, news, or a list of articles. iFrame Block (PageGridBlocks module) The new iFrame block uses layziframe to layziload any iFrame when you click a placeholder. You can upload a custom placeholder or, for YouTube/Vimeo, the placeholder can be loaded automatically and saved to the database (to comply with the EU General Data Protection Regulation). This is great for embedding external services such as YouTube, Vimeo, Spotify, Soundcloud, or others to your site. –––––––––––––––––––––––––– How to update from version 1: Please make sure you run the latest ProcessWire version before updating. I would also recommend to make a database backup for existsing websites before the update (just to be save). Then simply update the FieldtypePageGrid and PageGridBlocks modules.
    1 point
  5. This would also work: <?php if($page->matches("id=1042|1043")) ... ?
    1 point
  6. You can test multiple conditions in PHP if a if instruction as shown below if( $page->id == 1042 || $page->id == 1043 ) { // Do something here }
    1 point
  7. Thx for sharing, didn't know that as well! Not sure if your example is real or not, but I'd recommend something like this: $order->setOrderStatus('pending'); So your $page should better be an OrderPage (custom page class) and that pageclass should have this method: <?php ... public function setOrderStatus($status) { $this->setAndSave( 'order_status', $this->wire->pages->get("/path/to/order-statuses/$status") ); } I know the benefit looks little, but the code does not only get cleaner to read: <?php $page->setAndSave('order_status', $pages->get('/path/to/order-statuses/pending/')); // vs $order->setOrderStatus('pending'); It gets also more error-proof (what if someone/something created another page with name "pending" somewhere else in the tree? And not to forget your system will be better and easier to maintain. Imagine for example you change the path of your statuses one day. You only change the path in setOrderStatus() and you are done, rather than finding all instances of ->setAndSave(...). Also maybe one day the client want's E-Mail notifications on changed statuses... Simply go to setOrderStatus() method and add the mail code there. If you have several ->setAndSave('order_status', 'something') sprinkled around you might be tempted to add the mail sending on several locations or you might forget it somewhere and you'll have introduced an unnecessary bug ? PS: I'd even more prefer setStatus() but that's already taken by the Page baseclass. updateStatus() would also be an option. But setOrderStatus() might be the clearest anyhow ?
    1 point
  8. This week I've continued work on the page versions support that I wrote about last week. While the main PagesVersions module needs more work before it's ready to commit to the dev branch and test externally, it is so far working quite well in internal testing. I mentioned last week how it will support an interface where Fieldtypes can declare that they will handle their own versions. That interface has been pushed to the dev branch as FieldtypeDoesVersions. I've also implemented it with the Repeater Fieldtype, which is visible starting here. Repeaters are so far working really well with versions! As far as core Fieldtypes go, Repeater, PageTable and FieldsetPage are likely the only ones that will need custom implementations. For ProFields, RepeaterMatrix already works with the implementation in the core Repeater (already tested). It's possible that other ProFields will not need custom implementations, though not yet positive. The module that provides version capability is called PagesVersions and the plan so far is to make it a core module that provides API version support for pages. A separate module provides interactive version support in the page editor. I've built this module initially so that I can test versions more easily, but it'll be expanded to provide a lot more. Below is a screenshot if what it looks like in the page editor Settings tab so far: As you can see, you can Edit or Restore any existing version. You can also create a new version from the Live version, or any other version. And of course you can view and delete any versions. When you Restore a version, it essentially replaces the live version with the one that you are restoring. All of this can be done from the module's API as well. Note that the API is provided by a $pagesVersions API variable that is present when PagesVersions module is installed. The API method names and such are a bit verbose right now but may be simplified before it's final. // Get page and add a new version of it $page = $pages->get(1234); $page->title = 'New title'; $version = $pagesVersions->addPageVersion($page); echo $version; // i.e. "2" // Get version 2 of a page $pageV2 = $pagesVersions->getPageVersion($page, 2); // Update a version of a page $pageV2->title = "Updated title"; $pagesVersions->savePageVersion($pageV2); // Restore version to live page $pagesVersions->restorePageVersion($pageV2); // Delete page version $pagesVersions->deletePageVersion($pageV2); Thanks for reading! More next week.
    1 point
  9. Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!
    1 point
  10. Thank you very much @ryanfor working on this. For larger corporate sites this is a must have. We are using ProDrafts atm and got it kind of working with nested repeaters with some dirty hacks. Approval workflow like mentioned by @Pete would be awesome ?
    1 point
  11. @David Karich ProDrafts doesn't have versioning per se, it just maintains a draft version. So the version support will be something different, though the plan is that ProDrafts will be able to eventually use it for maintaining its draft versions. As for how the versioning works, it's very simple in that you have API methods to add, get, save, and delete versions of a page. That's the extent of it. While technically you could code a hook to make it save a new version on every page save, I don't think it would be practical, as a version is an entire copy of a page, including its files. Most likely one would use it to create a version intentionally, and perhaps work on it independently of the live version of the page. Or maybe they would use it to create a restorable snapshot or backup of a page's current state, before making some other changes. I think there are a lot of possibilities for how someone might use it, but for now I'm just focused on its API and making it all work reliably across different fieldtypes. @MrSnoozles A media manager is something I've not needed here, and I get off track and mess things up when I start developing stuff tools I don't have a use for in my own projects. Nearly everything that's in ProcessWire's core is stuff that I develop and maintain because I use it in my client work. When I need to share file or image assets across multiple pages I build a page or group of pages for the purpose, and that is ideal for my projects. A big part of the reason why PW as a framework is so modular and hookable is so that there is always the opportunity extend it in ways that are useful for your own projects. For example, @kongondo built what looks to be a really cool media manager for ProcessWire, though I don't have experience with it beyond reading about it and watching the videos. As for translations of the admin, PW's admin is already 100% translatable, so if you are seeing a mixture of English and another language, then that means that the language pack you have installed is missing translations. But that's something you'd need to ask the author of the language pack about. You can also always submit a pull request to the translation author's language pack, or create your own. PW makes this all very simple. Multisite is another example of a module that I just have not yet had a need surface for in my own work. Though I'm interested in it, so always looking for the opportunity. I'd have to come up with a case where I would use it and find it worthwhile. Otherwise I don't think I could do as a good job of a job as someone that is actively using it. I think the existing multi-site module(s) were built by someone (Soma, Apeisa?) that was using them in their projects. Worth mentioning too that PW will happily serve multi-site already, so long as you add all the hostnames to $config->httpHosts and use conditionals like if($config->httpHost === 'host.domain.com') to decide what content to serve. What I find useful in my work here is multi-instance, being able to boot other sites when and where needed, like we do on this site, where the modules directory actually comes from a separate ProcessWire installation, despite being delivered by the main site.
    1 point
  12. Thanks Ryan, I've really wanted something like this for a long time so good to hear you're making progress. ProDrafts is useful, but if this allows for a more complete version history like you might get in other CMS' and you can also then add in approval workflows down the line (separate module I reckon) that would be amazing too as I have a few sites where there are several people working on stuff at once and I know at least one of our mutual clients might find it useful too ?
    1 point
  13. There is a workaround if you're willing to edit the core: https://github.com/processwire/processwire-requests/issues/239
    1 point
  14. ProcessWire automatically sanitises the names of files that are uploaded to a Files field. For example, a file named "Café meals under $30.pdf" will become "cafe_meals_under_30.pdf" after it is uploaded. Since v3.0.212 ProcessWire stores the original unsanitised filename of each uploaded file, and this is accessible via $pagefile->uploadName https://processwire.com/blog/posts/pw-3.0.226/#file-and-image-improvements https://processwire.com/api/ref/pagefile/upload-name/ So if I have a field named "files" on my page and I want to provide downloads of the files with their original filename I can output links like this: $out = ''; foreach($page->files as $file) { // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } echo $out; So far, so good. But I want my site visitors to be able to view PDFs in the browser rather than force a download, yet if they do download them after viewing them I want the files to get the original filename. For this I can use a URL hook to deliver the PDF via PHP rather than directly loading the file. In /site/ready.php: $wire->addHook('/view-pdf/{page_id}/{filename}', function($event) { $id = (int) $event->page_id; $filename = $event->wire()->sanitizer->text($event->filename); if(!$id || !$filename) return 'Invalid request'; // Get the Pagefile via PagefilesManager $pm = $event->wire()->pages->get($id)->filesManager; $file = $pm->getFile($filename); if(!$file) return 'File not found'; // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); // Set headers and output the PDF content header("Content-Type: application/pdf"); header("Content-Disposition: inline; filename=$original_name_unencoded"); header("Content-Transfer-Encoding: binary"); header("Accept-Ranges: bytes"); @readfile($file->filename); return true; }); In the page template file: $out = ''; foreach($page->files as $file) { if($file->ext === 'pdf') { // Deliver PDF files via the URL hook $out .= "<p><a href='/view-pdf/$page->id/$file->basename'>$file->uploadName</a></p>"; } else { // Other files receive a download attribute // uploadName is entity-encoded when output formatting is on $original_name_unencoded = html_entity_decode($file->uploadName); $out .= "<p><a href='$file->url' download='$original_name_unencoded'>$file->uploadName</a></p>"; } } echo $out;
    1 point
  15. Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.
    1 point
  16. Thanks. I'll look into this and have a go at replacing it. In my usage scenario this isn't really an issue. I have some very small non-profits who don't want to pay much but have images and documents they want to host, and storing them locally on my VPS isn't really cost effective if they have a lot. If they're paying a low price and don't have to worry about storage, I don't think they're going to object if there's a temporary outage. I really appreciate you making this available. It's something I'd been thinking about for a while, and having a working module to modify will be so much easier than starting from scratch. I'd imagine my usage scenario may be useful to others too, so I'll be sure to update any modifications I make.
    1 point
  17. Wow... is all I can say right now for the moment. What amount of traffic or hits/second are you awaiting for that kind of setup? I built and ran pretty cheap and simple setups that handled up to about 30-50k hits*/day without noticable issues - ok, those sites were ProCached and running behind Cloudflare CDN (free tier), yet... it worked out. They probably could have handled even more. Nothing of my projects here are scaling horizontally, vertically or in any other direction ? compared to your setup. It's not within your league of setups by any measure - but here is how I built something that scaled back in my days very well: JS files came from sub[1-3].domain.tld super necessary parts were inlined file_get_contents of custom JS came from external sources CSS files came from sub[1-3].domain.tld almost all (critical) CSS was inlined file_get_contents of custom CSS came from external sources IMGs came from assets[1-3].domain.tld Cloudflare took care of GZIP and compressing and caching the output (not sure about brotli) ProCache took care of the heavy load prior to everything else as 95% of the whole site/s were cached (pre-cached by using a Sitescraper after each release) with a very long lifetime Asset and file handling were kind of static and strict without much options for custom solutions (wasn't really necessary for those sites) as the overall page setups were kind of minimal and simple (blog style - minimal differences) files like JS, CSS, IMGs came from other services and not my host, actually everything from a subdomain came from other services as the hosting was too cheap to handle lots of requests - I used Github, Zeitgeist (which is Vercel now - I guess), and some other services I can't remember, for that It was a bl**dy hell to make that work back then (BUT I had to save money I didn't have then) - but those were also one of my very first real projects with ProcessWire then (one of my first public 10 projects ever, and most of them were my own projects) - nowadays that setup would probably be still annoying in some parts, yet more feasible and easier to handle with way better results. My issues back then were limited database and webserver connections (those were over limit pretty fast) at my hosting companies (HostN*n, Dream***, Host***, Blue***, A2***, and such - super cheap) so I split all assets to other services and made them work via subdomains. In the very early days I only paid something between 0,99 USD/month for those sites. Later on 2,99 USD and even later 8,99 USD. It only became faster and faster. About a year before selling/shutting down those projects I paid about 60 USD/month/project. STEEP! Still the almost same setups could easily handle more than double/triple the hits*/day nowadays but with far better pagespeed results than ever before. Till today I'm happy with these kind of setups for my projects. The moment I reach at least 50k+ hits*/day with a project I return to that but with methods and services from today. What I use nowadays (for whatever reason - you will find out ?? webgo IONOS Hetzner Plusline Server Netlify Vercel Cloudflare Pages Cloudflare CDN Cloudinary Planetscale Runway Superbase * real hits/users/sessions - no fake requests ** paid plans for super high traffic sites, otherwise free tiers
    1 point
  18. Just wanted to share the simplest language switcher possible if you only have two languages: <a href="<?= $page->localUrl($languages->findOther()->first()) ?>">DE/EN</a> ??
    1 point
  19. Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.
    1 point
  20. I would give you 50 likes for that sentence if it wasn't for some passive-aggressive details in the rest of the post. I thought of just letting go, since your post seems to put a healthy stop on the discussion, but then, I don't feel like swallowing some things that I do consider unfair. I'm referring to these: I felt that everyone was very honest in their comments in the thread, and most of them (me included) said that they were not coders and had to learn a lot in the way. We also welcomed you and tried to give a friendly push to become better in what you do for living, since you said you're not happy with your knowledge. In general we don't know each other personally in the forum, but we still expect that people are honest, cordial, truthful in their opinions, and I think this forum in extraordinary in that aspect. You didn't do anything wrong in giving your opinions, but in my opinion, you are wrong when being deliberately unfair.
    1 point
  21. I know it was not you saying it, but if you also think that by simply calling PW a CMS we are attracting... what would you say about offering them a couple of ready to use thingies with the basics and then telling them that they have to construct everything else by themselves? Maybe it would help PW to attract more people to download it, but wouldn't it lead to more frustration and loss of time?
    1 point
  22. It's been a while that I used ProcessWire to build a 'regular' website. (Not that I really know what a regular website is). Recently I finished a planboard system for managing newsletters and placing banners for multiple Portals. At home I have a personal little project a Ajax driven website for a band (Friends of mine). So my context of 'improving usability' is expanding API capabilities. The devs here do understand really well that there are many use cases for ProcessWire. The sky is the limit, and beyond. You have to know that ProcessWire thrives on good will of the community. It probably only takes 1 man to stand up and start building a commercial themes download website. This theme-able profile should have some standards. So that there are plug-ins that are interchange-able. This all can be done with PW, because of the power of the API. This discussion is a really good discussion so we're all glad that these stories come up.
    1 point
×
×
  • Create New...