Leaderboard
Popular Content
Showing content with the highest reputation on 04/04/2021 in all areas
-
3 points
-
@Sanyaissues I see that there is used GD for the creation of the image variations, (at least some). Please, can you tell me which value you use(d) for "defaultGamma" in your $config->imageSizerOptions (or optional a options array passed to the variation creation)? BTW, the image handling is perfect! Different source sets for landscape and portrait orientation, (native) lazy loading, WebP variations with jpeg/png fallback, - everything is in! ? ? If you or the artist is interested in protecting the original images (the high quality 2000px ones) you may embed a .htacess snippet and the admin-image-proxy php from here.3 points
-
May not be @Sanyaissues' fault. I've had ProCache debug on and then unchecked the Debug checkbox to turn it off and debug stays on. Seems the empty checkbox isn't always respected. Just saying... Nice site ?3 points
-
3 points
-
Hi @fruid. I’m not going to get into this fully right now, just some suggestions. Most importantly: What you really want to do is just buy FieldtypeTable. It’s dope, trust me. Secondly, do yourself a favor and install Tracy. I have no idea how that error came about, but the stack trace will help you figure it out. If you can’t get it to work, I suggest starting a separate thread with specific questions and code snippets and Tracy traces. Your project is kind of out of scope for Bernhard’s tutorial here ? Well, you’re trying to make a Multi-Field (extend FieldtypeMulti), which is a little more of an endeavor than a single value field. Lastly, you can name a hook’s $event argument anything you want, if that is what you mean. $event is kind of a convention, but you might as well use $e or $hook or $args or whatever. You can even just leave it out if you don’t need it. Hooks work with callback functions. That is to say, it’s your own function. You name the function itself and its arguments.3 points
-
Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.1 point
-
Thanks all for the compliments! @horst Actually, I didn't add any values for defaultGamma, sharpenning, etc... I just set the quality to 90 in the $config->webpOptions. $config->imageSizerOptions('webpAdd', true); $config->useWebP = true; $config->webpOptions = array( 'quality' => 90, 'useSrcExt' => false, 'useSrcUrlOnSize' => true, 'useSrcUrlOnFail' => true ); Thanks for the tip to protect the original images.1 point
-
@horst: Thanks a lot, that was very helpful. First I lost overview a bit, then I found this older thread with you being involved too, that brought the final kick. Now this is working fine: $img_url = "https://example.com/index.php?cust=foo&id=1234&filename=d9b88153-89e4.jpg"; $img_query = parse_url($img_url, PHP_URL_QUERY); parse_str($img_query, $params); $filename = $params["filename"]; // result: d9b88153-89e4.jpg $page->of(FALSE); $page->imgs->add($img_url); // add image to multi-image field $imgs $page->save("imgs"); // save added image with unwanted name index.php // w/o trackChange() file seems to get renamed in file system but not in db $page->imgs->trackChange("basename"); // eq(0) is the right image in my case, other selectors are possible $image = $page->imgs->eq(0); $image->removeVariations(); // delete variations (thumbnails etc.) $image->rename($filename); // rename index.php to d9b88153-89e4.jpg $page->save("imgs"); // save changes to $imgs field I’m pretty glad to have that annoyance solved, so thank you very much once more. PS: The mess in the dumps above resulted from a typo in deleteAll() before saving the new image, so more than one image was saved.1 point
-
Yep, there are two images added. Why? If you want to rename that one that is named "index.php", you can try to get it by name from the Pageimages object. $img = $page->imgs->get("name=index.php"); // during testing, fisrt check what you have get in $img !! $page->getUnformatted("imgs")->rename($img, 'newbasename.jpg'); $page->save(); If this doesn't work, maybe because php is no valid image extension, you have to get the image files manually from the URL, beautify the file(base)name and add it after that to the images field.1 point
-
@rash, you first must (double)check what you get from $imgs->eq() or any other method. What do you see when you debug it, maybe with var_dump()? You also may try to use $imgs = $page->getUnformatted("imgs"); What objects / values do you get from $page->imgs and from $page->getUnformatted("imgs")? And if you have a multiple based object, how many items are in it, which one is the latest added one? $page->of(FALSE); $page->imgs->add($img_url); $page->save("imgs"); $imgs1 = $page->imgs; $imgs2 = $page->getUnformatted('imgs'); echo "<pre>"; var_dump($imgs2); die();1 point
-
For me it always was enough to remove unwanted entries from the modules table, regardless if the files were removed or still available.1 point
-
I got tired of looking up fontawesome icon codes all the time... https://marketplace.visualstudio.com/items?itemName=Janne252.fontawesome-autocomplete Using these settings: "fontAwesomeAutocomplete.patterns": ["**/*.php"], "fontAwesomeAutocomplete.insertionTemplate": {"**/*.php": "{name}"}, "fontAwesomeAutocomplete.version": "4" ?1 point
-
1 point
-
Please consider that flags should not be used to distinguish languages! See the notes here, visit the links:1 point
-
Hey @adrian I have lots of hooks firing in one project and I cant seem to find which one is causing a page name to change after save. The hooks debug panel is really helpful, but not in this case: Would it be possible to add links to that table so that if I click on "anonymous function" for example the file would open exactly at the place where this hook was added so we can inspect the code of the hook and quickly see what they are doing? edit: Ok, that was the "problem" - you might know this module ?? So my problem seems to be solved, but my request might still be helpful if it is easy to implement? ?1 point
-
1 point
-
I've created an issue in the requests repo - please give it a thumb up to show demand for such a feature! https://github.com/processwire/processwire-requests/issues/3961 point
-
Funding Processwire, Here are my thoughts, I think it could be a really good cash cow for many people, but only if they focus on something so many people out there want. Mind you I am not a developer, but an end user who needs developers to build stuff for me. Two of my sites are: www.rugpijnweg.nl and www.backpaingoodbye.com both made by people here on the forum. For me, like many others, my sites have to make me money. Therefore speed is important, hence I use procache on all my sites. Building blocks are important for easy building of pages that generate the action I need. Backpaingoodbye is good with that, all repeatermatric things in there. What I love about processwire is the speed and that anything can be built. The last part is also the problem, if I want something new, it has to be built. What I think processwire needs is something like www.thrivethemes.com, which is a separate company with an offering on top of wordpress, like there are more, but I particularly like many of the things they are making. What I hate about my sites with processwire, is that if I have some changes added to a site of mine, it just is a stupid nightmare to port new stuff to other sites that use the same profile. I guess rockmigrations would be great for that, but there you go, I need a developer to run things again, and I now have 4 sites running the same profile. For that reason I am now even considering moving over to wordpress, I got me a subscription to thrivethemes, but I HATE wordpress with a vengeance... all these stupid updates all the time. Thrivethemes itself is buggy and does not make sense, it produces slow sites, but hey I can get a lot of functionality. The underlying problem with processwire and its funding is that it is IMHO too much tech oriented, brilliant minds who build incredible things, but the huge market out there is just forgotten, and wordpress gobbles it up. And then people build stuff on top of wordpress and make a very good living. So here's what I believe would work: - get a group of people together and decide on & build a basic site structure that has all the fields anyone needs, with upgrade paths in place should the structure be extended - on top of this site structure build a storehouse of repeateable blocks with a page builder like thrive themes is using, but then better, more processwire like - then have the designers go crazy on developing a number of front end variations that change the look and feel of the whole site, just by pointing the whole show to a different css file - have some developers working on creating more building blocks focused on different niches, par example the coaching business would require agenda booking, same for hairdresser salons. - this way it would be possible to offer niche specific sites, including hosting I have ideas how this could work, and would like to hear if people are interested to develop these ideas further Let me know1 point
-
Great update - working with access control got a lot easier today ?? Access Control ProcessWire has a powerful access control system. When using RM to create new templates and pages it is quite likely that you also want to create roles and define access for those roles on the new templates. The basics of access control can easily be done via RM - for more advanced topics you might need to implement custom solutions. PRs welcome ? Let's say we created an Events calender and we wanted to store all events (tpl event) under one page in the page tree. This page (tpl events) would only allow pages of type event. To manage those events we create a new role on the system called events-manager. $rm->migrate([ 'templates' => [ 'events' => [...], 'event' => [...], ], 'roles' => [ 'events-manager' => [ 'permissions' => ['page-view', 'page-edit'], 'access' => [ 'events' => ['view', 'edit', 'add'], 'event' => ['view', 'edit', 'create'], ], ], ], ]); On more complex setups you can use the API functions that are used under the hood directly. For example sometimes I'm encapsulating parts of the migrations into separate methods to split complexity and keep things that belong together together: /** * Migrate all data-pages * @return void */ public function migrateDatapages() { $rm = $this->rm(); // migrate products (having two custom page classes) // these have their own migrations inside their classes' migrate() method // where we create fields and the template that the class uses $product = new Product(); $product->migrate(); $products = new Products(); $products->migrate(); $rm->setParentChild(Products::tpl, Product::tpl); $rm->setTemplateAccess(Products::tpl, self::role, ["view", "edit", "add"]); $rm->setTemplateAccess(Product::tpl, self::role, ["view", "edit", "create"]); // same goes for all other data pages // ... }1 point
-
@adrian It's like an index for page URLs/paths. Usually PW has to join every page in a query in order to know its URL. So the PagePaths module provides a more direct and theoretically faster route. But in my experience, it's not really faster until the URLs get long (like in cases where PW would have to do lots of joins to determine the URL otherwise). The other thing it does is that it lets you perform $pages->find() partial text matching operations on the url/path, which you can't do otherwise. The only place where it adds overhead is if you change the name of a parent page, it then has to re-index all the URLs for everything below the parent. It's not installed automatically because most people don't need it, and it doesn't support multi-language URLs. But it's handy to have when it crosses over with your needs. I'm good to provide an option for findRaw to return an array of basic objects if one requests it in the $options. But for most I would suggest sticking to the array because it's good for it to be clearly different in syntax from a regular page. That's because it's all raw and unformatted data, so it's not going to be safe to swap between find() and findRaw() in most cases and good to maintain clear differentiation. For instance, when using something from findRaw() for output, you've got to be sure to entity encode anything you output, etc. Plus, one reason for findRaw() is to provide the lowest level path to the raw data, and I think a PHP array is probably the lowest level, least overhead way of doing that. But having an option/alternative for a std object seems fine to me.1 point
-
I once asked Ryan if he plans to add language files to his Pro modules. He doesn't plan to do so. His reply was (more or less) that most people using these modules were developers, not authors (clients), and a developer surely understands English. Fact is, many of the Pro modules are not only being used by superusers, so that's kind of a weak excuse. It's a lot of work translating e.g. a Lister Pro language file. Of course, for German, I only did it once, and then copy files over. Other eco-systems have solved this way better imho... On a side-note: Ryan is maybe missing out on marketing arguments here... it would be easy for him to aggregate at least a dozen translations for his modules from existing developers / agencies who bought a license and translated everything on their own. In return, he could give away licenses or free access to the VIP support boards to those ppl who translate Pro module JSON files ( A classical win-win situation ?). For some ppl, it makes a difference if a module is already translated in x languages or just English. That's a robust sales argument right there.1 point
-
I get different results. Using the Sanitizer::translate constant in the second argument means the sanitizer will use the character replacements defined in the InputfieldPageName module settings. So if you only need to account for the German language you can edit the replacements for ü, etc, to achieve a result like that shown above.1 point
-
I’m around… You can contact me on noelboss.com if I’m not here… I would also try the latest API Modules: https://processwire.com/modules/app-api/0 points