netcarver

@LostKobrakai Thanks for posting your solution. Looks a little more flexible (allowing breaks and paragraphs) than the one I made up.

You could add something like the following (untested) function to your global functions or a common init file to do the job of dealing with different line endings and conversion to paragraphs... function nl2p($str) { // Change \r to \n... $out = str_replace("\r", "\n", $str); // Change runs of \n to just a single \n... $out = preg_replace("/\n{2,}/", "\n", $out); // htmlenitites... $out = htmlentities($out, ENT_QUOTES, 'UTF-8'); // Change each \n into a paragraph... $out = '<p>' . str_replace("\n", "</p>\n<p>", $out) . "</p>\n"; return $out; } This also takes care of the htmlentities() call for you. Hope that helps.

@LostKobrakai Although it might not be the best solution, have you tried something like Textile before? There's a module available for it and you'll need to use the restricted version if the input is coming from untrusted sources like social users. It should handle the differences in \r, \n, \r\n etc but might be a little more complex than you really need. Whatever you end up doing I suggest you always pass the finalised field values through htmlspecialchars() or htmlentities() before rendering them on your site.

@Douglas Welcome to ProcessWire and the forum. That's a nice site conversion - I like it. As an ex-TxP user myself, I'm glad to see others coming over to ProcessWire. Enjoy your time here!

@Dan Can you let us know what timezone you work in? (There are a lot of experienced European PW users who might/might-not want to work in a US timezone or vice-versa.) I'd also like to echo pwired and Christophe's request for more information about what you need here. When you say "editing" and "edits" are you talking about editing the contents of existing fields within the PW admin or editing code in PWs templates or something else? If its code, is it limited to PHP or do you need help with the CSS and JS side of things too? Are you converting a client site from WP to PW? Details (where possible) will help. If an NDA is needed, declaring the fact may help. Thanks, Dan!

Related to Pete's 3rd point above: It might be helpful to potential respondents if people posting jobs here would also state what timezone they are operating in.

Apologies for the confusion Ivan, I had no idea that asking my avatar to wear a mask would lead to confusion about the shopping cart module - there is no link between the two. I'll let my avatar know that he nearly caused an international incident in the PW community!

BTW, WillyC was way ahead of the curve in this regard.

Inspired by Pete's recent change to his avatar and due to all the revelations this last year about digital spying, I decided it was time to take action to hide my avatar's identity from the powers that be. Advising my avatar to don a mask seemed like a simple step he could take towards that goal. I'm glad others are starting to take an interest in their avatars' rights too.

I think pideluxe has a mask too.

Maybe including Nico's module in either a slightly modified default profile or a modified copy of it called something like "First Time User Admin" or "Guided Config" (or something better) might be a suitable place.

¿Qué pasa?

@sforsman These are indeed very good points and serve to illustrate a clear difference between my previous application requirements and using the api in PW. In this case I believe you are right.

QBox.co - a simple shop for some PW modules.

@sforsman Thank you for your two posts! What a great summary you made two posts up; loads of information and good points. Just want to pick up on a few of them... The hardware implementations are fast but that tiny loss of precision at high exponent values can represent huge absolute errors. Floats really work well when you don't mind about precision but you need to have a datatype that allows calculations over a huge range of values. This seems to assume that a decimal is the only possible MySQL fieldtype that can solve the problem. Seeing as PHP uses strings to do BCMath stuff, isn't it possible to store an arbitrary precision variable in a straight MySQL varchar or text field? I've done that in the past and handled all the calculations in the PHP application using BCMaths functions and it's worked very well. This approach would mean you don't have to go and alter your column if you need to start storing values outside of the initial storage range of the decimal column (as long as you made the varchar pretty big.) The approach wouldn't work well if you want to do some maths in queries or stored routines of course.

Could the JS-driven form-to-wizard approach mentioned here work in your case?

@Ivan Thanks for posting that. Yes, it's a known issue. I still have to re-show the back button on payment form cancellation. And yes, I'm very privileged to have been given access to Apeisa's next-gen shop suite for testing.

Hi Craig, Thanks for pointing that out - guess I'm just used to having that character available in my installed fonts. I have removed it.

Announcing QBox.co; a simple native PW shop that I'll be using to sell my commercial PW modules. This site has been put together with the aim of giving me an independent platform to sell some of my more specialised packages. The selection is limited at the moment but more will be added soon. Actually, a lot of the packages that I'll be offering on QBox are not limited to ProcessWire applications - they will often provide functionality that you can use in other PHP projects. Before you ask, the shop is running an, as-yet unreleased, version of Antti's shop module suite for PW with some changes to provide additional functionality. Payment is handled by integration with Stripe.com and you'll need Javascript enabled to make it happen. I've already opened a dialog with Ryan about getting the modules represented on QBox.co in to the official PW shop site and we'll see how that progresses. In the meantime, please feel free to let me know if you stumble over any problems; have useful comments or criticisms; want to know anything more about any of the modules offered there or just like what you see.

That's great Adrian, thank you!

@clsource It currently provides two implementations of thread-safe counters. The first uses PHP file locks in blocking mode and stores the counters as files on local disk (under your assets folder). This allows the counters to be migrated alongside your application code if needed. The other, faster, implementation uses Redis as the counter storage engine leveraging its atomic increment and decrement functions and atomic LUA scripting. The neat thing about the Redis implementation is that the counters can be shared between multiple instances of your application (or even different applications) running on different servers. This really allows things to be distributed. It does, however, require some extra configuration work to get the Redis server set up in the first place (but that's actually pretty simple under debian and ubuntu at least.) Both implementations have mechanisms built-in to allow recovery from the deletion of (or simply forgetting to migrate) the underlying counters. I hope to have this module available for sale over the coming weekend on my first native PW shop site and I'll post more about it then.

@clsource Transactions cover quite a wide area but using DB transactions isn't the only way to address the race condition for that last item or items that you have in your use-case. Here's a solution using a module I'm developing and hope to release commercially. How does this look? /** * Somewhere in your application you load the module */ $counters = $modules->get('ThreadsafeCounters'); /** * In add-to-cart logic you request a given qty of product. * You may get zero (if all taken), the number you requested (if many still left) * or some number in between (if there are too few left to fulfil entire request.) */ $reserved = $counters->reserve('product_qty_remaining', $number_requested); if (0 == $reserved) { /** * All taken - sorry! */ } else if ($reserved == $number_requested) { /** * Entire number can be fulfilled. */ } else { /** * Only a partial fill is possible. * If you don't want to handle this case in your application you either return * the $reserved qty straight away or call reserve() with the $all_or_nothing * flag set to true: $reserved = $counters->reserve(<counter_name>, $qty, true); */ } /** * If a sale falls through later (perhaps payment rejected) simply return the * number the customer ordered... */ $counters->inc('product_qty_remaining', $qty_of_product_in_order); This uses thread-safe, persistent, counters to prevent races and simplify application logic.

I just tried Valery's first method of editing the admin template to give a 404 to unprivileged users and could then no longer access the login page from a second machine even when using the correct login page url. Fortunately I was still logged in as superuser on my dev box and changed it back. Looks like editing the .htaccess or nginx config might be a safer way to go.

I once watched something on TV here in the UK that compared "Crimewatch UK" to your NZ counterpart. In the UK program the police were trying to solve horrible crimes like murders and rapes. In the NZ version they were trying to trace the owners of lost property. I wish the UK could be more like NZ in that respect.

Hi LK, I was looking at this bit of your issue. Both of the modules I suggested allow variable substitutions. I believe adrian and reems have the pdf-generation part of your question covered.