Leaderboard
Popular Content
Showing content with the highest reputation on 01/06/2022 in all areas
-
Hello Padloper Alpha/Early Beta Testers. Shortly after this post, you will receive an email inviting you to access and test Padloper 2. Thanks! If you don’t receive an email within 2 hours, please let me know. A few things to note before you dive in. What to Expect Padloper 2 is a native ProcessWire module. It is not an SPA. A previous iteration powered by VueJS was discontinued. Instead, there is some sprinkling of htmx, alpine.js and Tailwind CSS here and there. Bugs: how many? We’ll find out soon. There are a lot of bd(), even db() calls left, deliberately, in the code. Most (all?) have been commented out. They have been left in the code for a reason; to help debug the product. A shop app that you can use incrementally. Many of the features are optional and can be left out (or added later) at install. Inbuilt invoice and PayPal payment gateways/systems. The latter uses V2, the latest PayPal SDK. What not to Expect Although it boasts a rich set of features in its current state, a number of features have not yet been implemented. Some have been implemented but not fully, so may not work as expected. In the expression of interest form I listed the features I’d want to implement next. I asked you to express your preference for these. I’ll be guided by your choices when prioritising the next set of features. Implemented but Incomplete Orders (backend) Manual order creation (creating orders via GUI) is incomplete. Actions including print invoice, mark order as complete, etc are incomplete. Products (backend) Product variants should lazy-load when the product is being edited. Currently, they are all loaded and can slow down the page if they are many. Checkout Settings (backend) Some of the settings including abandoned orders follow-up are not yet functional. General Settings (backend) The settings to limit allowed image and file extensions is not yet synced with the respective image and file fields. Shipping Zones (backend) It is not possible to prevent countries from being added to more than one shipping zone. Shipping Rates (frontend) If more than one shipping rate is matched for a customer for a given shipping zone, it is not yet possible to let the customer select their preferred shipping before finishing their checkout. A side note: matched multiple rates can be desirable in cases you want to offer more than one delivery method to your customers, e.g. a free but slower shipping and a faster but paid-for delivery. Downloads (frontend) Delivery of digital products is incomplete. Not Yet Implemented Access (backend) Access control via permissions and/or roles not yet ready. Other Desirables Not in any particular order and planned for future release(s). Bulk product images management Customer management Discounts Staff management Shipping classes Notifications management Detailed Analytics Additional in-built Payment Gateways (Stripe, etc.). Better management of abandoned baskets Invoice generation and management Known Issues PayPal showing lots of JavaScript console errors. These are all related to CORS as far as I can tell. PayPal struggling with some floats (prices). It will crash and payment will fail. Maybe this could be solved by charging in cents (in PayPal) but I haven’t yet found a way to do this in V2. If you have any questions please ask here. I will contact you later for where and how to report bugs. Please don’t use this thread for that. For generic issues, such as not being able to install, etc., please let me know in this thread. Thanks and happy testing!4 points
-
This might possibly be connected with an issue that I raised here https://github.com/ryancramerdesign/ProcessHannaCode/issues/26 and here but I haven’t received any response2 points
-
Depends on what you guys want me to prioritise. I haven't looked at it in detail but from the expression of interest form it seems that Stripe is pretty high up the list. <?php namespace ProcessWire; $this->addHookAfter('PadloperCart::getProductPrice', null, 'customProductPrice'); function customProductPrice(HookEvent $event) { $product = $event->arguments('product'); // get the product field with the price $stock = $product->padloper_product_stock; // grab the price $price = (float) $stock->price; if (wire('user')->name ==='my_best_friend') { $price = 0.01 * $price; } $event->return = $price; } Padloper is very versatile. You can use it as a POS using the backend only; as a full ecommerce solution with a front and backend or as a headless CMS or API only shop. :-).2 points
-
New version 1.1.5 I've fixed issue with editing in repeater's template context https://github.com/uiii/AdminHelperLinks/issues/1 and disable focus on tab press (was annoying when switching focus between inputs).2 points
-
1 point
-
If I have a float or double field in the Admin with a value such as -0.00001253 then saving initially shows this as -1.253E-5, which is fine, but saving again changes it to -1.2535 (v3.0.184 and 3.0.190) In my FieldtypeMeasurement module I have fixed this (in a not yet released version) by using a text field and using (float)$value in the wakeupValue rather than $sanitizer because $sanitizer->float($value) returns -1.2535 from -1.253E-5. Is this a bug or is there something subtle that I don't understand here? It seems to me that InputfieldFloat may be using $sanitizer->float() which does not convert the scientific notation.1 point
-
Confirmed on PW 3.0.188 and 3.0.191. Also, the HTML5 input for floats seems to be broken? It tells me the nearest valid values are -1 and 0 when trying to input -0.00001253. You should open an issue on GitHub about this. It seems pretty messed up for PW to fudge numbers by a factor of 100,000.1 point
-
Yes, this is the exact reason why I asked about it. In its current state it's not even as complete as Padloper 1 so the most I could do is playing around with it. And that would not be a proper beta test I'm afraid. It's been years since I last used PayPal for anything so Stripe is a must have on my list, I'm not so much into custom solutions though...1 point
-
Thanks, Francis. Quick question: Is it an introductory price? Will it increase when you release it to the public?1 point
-
1 point
-
Several updates have been pushed to the module. The latest one concerns the fireOnRefresh method / strategy. If you are using this technique together with bootstrapping ProcessWire be sure to test everything as this change might introduce different behaviour than before! From the readme: Note about fireOnRefresh() Prior to v0.0.82 the fireOnRefresh did NOT fire in bootstrapped environments. This is because ProcessWire by default runs as guest user when bootstrapped and the fireOnRefresh method did not attach any hooks if the user was no superuser. That was a problem for me because a $modules->refresh() did not trigger any migrations when invoked from the commandline. To solve that issue v0.0.82 introduces another concept: fireOnRefresh fires always after Modules::refresh even for guest users. If you need to prevent RockMigrations from firing actions that where attached via fireOnRefresh you have two options: Setting a constant: define("DontFireOnRefresh", true) Setting a config property: $config->DontFireOnRefresh = true; Note that the setting must be available to RockMigrations BEFORE the action gets attached via fireOnRefresh. This is best explained by examples: define('DontFireOnRefresh', true); include("index.php"); // fireOnRefresh is triggered here $modules->refresh(); // this will not trigger any migrations We define the constant before ProcessWire gets loaded and therefore any module attaching migrations via fireOnRefresh will actually NOT attach any migrations because the flag to prevent that is present when the triggered from init() or ready(). include("index.php"); // fireOnRefresh is triggered here $config->DontFireOnRefresh = true; $modules->refresh(); // this WILL trigger all migrations! In this example the migrations will be triggered because the migrations have been attached BEFORE the config setting was set. In other words the flag was set too late for RockMigrations to realize it.1 point
-
@Jan Romero, guess what version the site is on: 3.0.191 ? I always use the dev version for new sites and never ran into any issue. There's always a first for everything. ? Thanks a million, I searched the web and the forum up and down but didn't find it. You saved my day.1 point
-
I think you may have downloaded the dev branch at an unlucky time. Looks like this issue which has since been fixed. If you’re on that version, try updating.1 point
-
Just a quick question: I cannot see any sign of promotional coupons/discounts in the screenshots nor in the text of the docs. When do you think you might be able to start working on it in the future, the earliest? Regarding the projects I need to work on, coupons/discounts and Stripe payment is the only major missing bits I could spot so far. It would be great to see them being implement during the beta period. As far as coupons/discounts are concerned, first and foremost I am thinking of a developers' API (and/or hooks?) upon which we can implement virtually anything we might need to. Usually my clients do not even want to touch this area in the webshops I manage, so for me there is no need for an admin GUI at all. Sure, being able to manage coupons/discounts in the admin will be a must for many, but to start with, a versatile way to tap into the calculation of the Total price would be preferable as most of the time I am asked for promotional methods which often not pre-made in any system out there at all. And this also includes adding gift items to the cart, and sometimes such gifts are not even sold in the store, being promotional gifts only. So I am mainly interested in an API which allows us to modify the Cart / Coupons / Subtotals / Shipping / Insurance / Total based on any custom requirement. Meaning adding any customs cost as well, when required. I hope this makes sense :)1 point
-
Hey @Moritz! I use RockMigrations to handle most of the API related stuff along the initial Migrations module, which has a CLI interface letting me run pending migrations per site and keeps the track of it. The sites all share the same features and templates, nothing can be added as a "site specific feature" that involves a "custom pw stuff" in the database, it religiously needs to be in sync. I use bitbucket pipelines for deployments, and it's a very simple script involving rsync and running the Migrations CLI. I do write everything that involves a "new feature" regarding fields on a page, repeater matrix, etc. I'd say once you got it figured out, most of the time i'm copy pasting between migrations and adapting. I'd love to get in sync with some sort of automated testing (end to end with cypress?), but right now it just involves manually testing, and deploying to a few sites to test, fix otherwise and deploy again. I guess this is more of a management issue?? Maybe I am not understanding your full perspective here. No db dumps becase as you mention, it will mess up content. HannahCodes I migrate using the text version export of the hannahcode haha Module updates I guess just upgrading the files?? Haven't got into a deeper issue where something breaks while doing these. I think, up to know, I have just installed new modules. I keep processwire install outside of this equation, I am not sure if this was a wise decision, but it is like that lol One thing that is super important that I haven't though very well is rollbacks. Right now I basically would just run another migration on top, chekout/cherrypick from earlier branch or sth. Though haven't had enough time on this setup to mess up like this and need a rollback or where just doing a migration on top wouldn't work.1 point
-
1 point
-
Probably my method is in the dinosaur category, but it still works without spending too much time on migrating a database: If I do not mix up production with local then it is fool proof. It takes less than 15 secs from start to finish to clone a small database including all the keystrokes I have to perform at the beginning. Sure, it is the other way round regarding migrating, but for a one man show it is not a big deal. When modifying settings in production, I sometimes have to do the cloning more than once but since the whole process is so fast, for me it is a non-issue. "I am still waiting" for an official automated migrating solution included in the ProcessWire core :P1 point
-
ATM I simply use the manual export <> import function from PW for fields and template settings. Every time I also have to alter field and or template settings, I write down the timestamp on a pad of paper when I start to do so and then collect a list (on the left side) of all fields I touches in the next time until deployment, (and on the right side I collect all template names).* When I'm ready for deploying, I may or may not shut down the live system for a short amount of time, depending on the amount of changes, then collect from the DEVs export selector all needed fields, copy the export json and drop it into the targets fields import field and proceed. Next step is the same with template changes. There is no need to shutdown a live site for long time. Mostly when I had large deployments, it was closed for one hour, but most of the time I do and have done those db migrations without any maintenance mode, because most of my sites uses ProCache. If it really would matter, I can prime the cache by crawling the site once before starting to deploy. It is not comfortable and also not the best I can think of, but it's not nearly as uncomfortable as described by @bernhard? Using these functions is not nearly as error prone as manually writing EVERYTHING into one schema or another for every field and template change. Noting everything by hand is not error tolerant for typos, I might forget to note a value, a change to a template, etc. All this is avoided by simply copy-&-paste ready generated JSON directly from PW. No typos, nothing forgotten, nothing added. Not perfect but for me much faster, easier and safer than writing everything down again by hand. PS: * In case you are not sure if you have written everything down on paper, you can generously include additional fields or templates in the export. In this case, it is better to have more (or even all) than too few. All unchanged settings will be recognized by PW during import and will not be processed further. ?1 point
-
Yes, RockMigrations Yes Yes It depends. Imagine you already have a setup using RockMigrations and your class uses code like this: <?php $rm->migrate([ 'fields' => [ 'field1' => [ 'type' => 'text', 'label' => 'Field ONE', ], ], 'templates' => [ 'my_template' => [ 'fields' => [ 'title', 'field1', ], ], ], ]); And you wanted to add 2 new fields and show those fields in a 3-column layout in your page editor. Using RockMigrations: open the file that holds your migrate code in your IDE (eg /site/classes/MyTemplate.php) add some lines of code (it's copy&paste most of the time and really easy once you are used to doing so): <?php $rm->migrate([ 'fields' => [ 'field1' => [ 'type' => 'text', 'label' => 'Field ONE', 'columnWidth' => 33, ], 'field2' => [ 'type' => 'text', 'label' => 'Field TWO', 'columnWidth' => 33, ], 'field3' => [ 'type' => 'text', 'label' => 'Field THREE', 'columnWidth' => 33, ], ], 'templates' => [ 'my_template' => [ 'fields' => [ 'title', 'field1', 'field2', 'field3', ], ], ], ]); run the migration add code that uses the new fields test your results, commit and push to staging/production Not using migrations, option 1: login on the live system add new field2 set column width, save add new field3 set column width, save go to setup > fields > edit > field1 set column width, save add code that uses the fields on live system hope that everything works and none of your site visitors sees anything from what you are doing... if anything goes wrong: restore the backup you took before creating your fields what? you forgot to create a backup? ok... you took care of that and lazycron is doing backups every day! write an email to your client that explains that you had to restore a database backup from last night, which means that his website lost XX comments, or YY orders, or ZZ new entries ... That means that option 1 CAN be quicker, but can quickly get a lot more time-consuming than properly migrating your fields. Not using migrations, option 2: take your site offline to make sure that you don't lose any live data (you already mentioned that) make a db dump on the live system import data from the live system to your dev setup go to setup > fields > edit > field1 set column width, save go to setup > fields > edit > field2 set column width, save go to setup > fields > edit > field3 set column width, save create a db dump of your local system upload your local db dump to your live system take your site online again Option 2 is a little more secure, but imagine you are working on that project as a team... You'll quickly get a huge overhead in not using migrations! You need to tell all your colleagues what you did somewhere. Imagine one of your colleagues works on a different feature at the same time and pushes changes to live overwriting your changes... You'll be in trouble! RockMigrations was built for all those things you mentioned. And we have not even been talking about reusing things you do... Using RockMigrations you can literally copy&paste setups from one project to another. That can save you a huge amount of time. All of what I mentioned depends a lot on how you work, what projects you work on, what clients you have etc... The fact that you are using automated deployments already and asking those questions sounds like you should definitely give RockMigrations a try though ?1 point
-
Real programmers use butterflies To everyone using git for automated deployments: How are you handling field/schema changes in between environments? And what about module updates/new modules, module configuration, custom module data (like Hanna Code shortcodes)? And everything else that's in the database but affects the CMS, like selecting a specific page as allowed parent in a Page Reference field? A database dump is of course an option, but once a site is live you can't just import the dump in production since it will overwrite the live contents. Are you writing migrations using one of the migration modules by hand? For every single field, field setting etc? Assuming you're able to handle all the edge cases (mentioned above and otherwise) with custom migration code, isn't that hugely time-consuming? Particularly when it comes to creating complicated field setups like Repeater Matrix fields with multiple types, where some settings are stored separately from the field settings and not all properties are documented or type-hinted … Something else? Anyone got a setup that allows them to use git and deploy from dev to staging/production without manual steps? If so, how are you handling the above issues?1 point
-
Happy new years too! Thank you so much for sharing your setups, this has been an excellent thread, and its nice to see some people in a similar boat to me (and those perfering as little setup as possible)... Love that quote about "Real Programmers, Don't Use Frameworks.." I feel like I subscribe to this but without the expertise to actually pull it off ?♂️ I might look again at docker / vagrant / Virtualbox again and see if I can find a good local workflow on my M1 Mac (for referrence). I've now got so many links to check out, will report back if I hit any revelations. Please continue to share your setups as maybe useful for other peeps coming fresh too PW too.1 point
-
What ever lived before dinosaurs, I'm one of those ? I use Nova as Code Editor which has a FTP-client builtin. Most of the time I'm working on the live-server. ProCache takes care of my scss-files Modules: PrivacyWire, Jumplinks, ProtectedMode, lot of the ProModules, … ProfileSiteExporter for moving Sites I also do not offer hosting Even with a limited setup as mine, there is a lot possible with ProcessWire. What a great CMS and community. btw: Happy new year to you all!1 point
-
Developing on Linux (currently Arch/KDE Plasma) for the last 16 years. Would never go back to proprietary alternatives. Why pay for something that should really be free for all? Devtools: Editor: VSCodium with PHP Intelephense, GitLense, PHP Debug (xdebug support), Prettier (Code Formatter), Todo Tree and @bernhards PWSnippets. Local dev env: after having used vagrant for a long time, about 4 years ago I switched to https://laradock.io/ for local docker environment. Ensures portable environments across multiple machines PW modules used on almost every project: TracyDebugger, WireMailSmtp, ProFields (mainly for Repeater Matrix), TablePro Asset building pipeline: npm scripts / gulp / webpack. Will have a look into Laravel Mix. Might save time although I actually like to fiddle with all the configs. Deployment: for older and ongoing projects mostly SFTP. For new projects git with git hooks. This is so much cleaner. Not using any service but creating own git hooks on the server. git must be available on the production server. Staging servers used rarely. Mostly deploy from local to production. Hosting: I do not offer hosting services. This is up to the client. Personally I use https://uberspace.de/en/ which is a command line configured shared hosting provider from DE with a pay what you want pricing model1 point
-
Demo site (frontend) is here. I'll do a write-up about it soon. The cart is htmx, Tailwind and alpine.js powered. Borrowed bits of templates here and there, threw in some Tailwind CSS components and this is what we get. Oh, yes, all the blemishes are mine. Site is not optimised but it is fast enough. It should give better feedback after item is added to cart. Will work on it later. Full checkout works. The PayPal widget will not charge you though. It will just crash (with a lot of grumbling in the console). Over the weekend I'll set up a GitHub repo with this demo as a starter site for our testers (especially). I also plan to wrap up the docs and prepare access for testers ready to download by Monday. I'll send you (testers) an email in this respect. After (or even before) that I'll write up a bit about what to expect in this first release and what not to expect. Happy new year.1 point
-
@Jonathan Lahijani - I love it - your comments have a very similar tone of ridiculousness that my list has :) Firstly, I am glad you found Forklift - I use it exclusively and I actually love it for FTP because I can open files directly from a remote server into my code editor and saving the file will send it straight back to the server. Obviously the dual pane is essential, especially given the stupidness of the cut / paste situation. The other crucial thing it has for me is being able to order folders first, and then files - that is truly the dumbest thing in MacOS. The Enter to rename drove me crazy for a while too, as did not being able to delete a file by hitting the delete key - don't even get me started on the lack of an actual delete (vs backspace) key on laptop keyboards :), but I am mostly over that now. These days I only use the trackpad (because damn they are nice on macs - pity the magic mouse is garbage), so the acceleration stuff doesn't bother me, but I can imagine. Oh, and yes to the window focus stuff - definitely annoying. Another utility you should try is BetterTouchTool - it has lots of mouse / trackpad settings, along with window features like snapping, but most importantly bringing proper window maximizing (rather than full screen) with the plus icon. Regarding having Finder first on the dock - I almost never use the dock because I have Alfred, so app launching / switching is with the keyboard. You might also like to try Hyperswitch for a more Windows like dock. Anyway, despite all the bad UX stuff, I generally do find it much more stable and it's amazing to have not reformatted / reinstalled the OS once in 10 years. I also love the unix basis to the OS - I know there is now WSL, but it wasn't around when I was using Windows.1 point
-
Funny you say that because I wrote a similar list as well. Here it is with some added commentary. As you can see I solved some things but listed them anyway and other things I didn't list because I solved them. general when clicking something in an unfocused window, the first click will focus the window; another click must be made to actually do something in the window I didn't realize how much this annoyed me. I thought Front and Center fixes this but it doesn't. finder (and Finder replacements) can't move or even remove the finder icon in the dock I don't want Finder to be first; to counteract, I've added a bunch of spacers so it's visually separated from my core programs (vscode, chrome, forklift, iterm) there is no "cut" option in finder (must copy, then use the move/paste with command + alt + v -- requires 2 hands) can't have custom categories in finder (just favorites, locations, icloud and tags) can't have the main folders load from a custom location like you can in windows; must use symlink instead this messes up how Finder search works hitting 'enter' on a file or folder does rename instead of launching the file / entering the folder (naturally, 'enter' seems like the right key to hit to ENTER a folder, not rename it) this means i have to use whatever the keyboard shortcut macOS wants you to use, and I don't remember what it is, but I remember I must use 2 hands -- ridiculous! the files list does not refresh automatically if a new file was written somewhere else (!) I use ForkLift as a replacement to Finder, but nothing in the macOS ecosystem comes even close to XYplorer (I used that for 13 years and it's updated constantly; it's like the ProcessWire of file managers... a Swiss Army Knife) mouse mouse wheel uses acceleration which makes sense for touchpads and mice without an actual WHEEL; it's not linear like you would expect counteract with https://github.com/emreyolcu/discrete-scroll the fact that macOS uses acceleration based scrolling for notch-wheel mice is ridiculous. that doesn't make any sense. macOS mouse movement physics is weird (at least compared to Windows) using outdated steelseries exactmouse to counteract that program is from 2010 (!); there's nothing more recent! no middle-click + scroll use "AutoScroll" extension in Chrome; it doesn't have the same feel like in Windows chrome can't open a new tab inside a chrome app like you can in windows; must first focus a regular chrome window other software Transmit (the SFTP client) doesn't support folder bookmarks (really wish it did so I don't have to use FileZilla; I don't want to use ForkLift for SFTP)1 point
-
I have added a request "findRaw should have support for joining parents and references" (and also for getting option field titles) here https://github.com/processwire/processwire-requests/issues/427 @adrian @thetuningspoon1 point