Leaderboard
Popular Content
Showing content with the highest reputation on 06/27/2014 in all areas
-
This Textformatter module for ProcessWire enables you to break up a single textarea field (using either TinyMCE or CKEditor) into multiple pages. You include all of the content in a single rich text field and separate each pagination with a line of hyphens (5+). When rendered on the front-end, the user will see pagination links at the bottom of the page enabling them to move forward and backward through the content/article. Also included is the option for title pagination. That means assigning a title/headline to each pagination and giving the user a list of those titles they can click on to move to each section of the article. Example of this module in action Documentation and customization options GitHub Page Module Page Download ZIP Install class: TextformatterPagination8 points
-
As for your wish request. It is already possible to track changes, what -> old -> new value. $user->setTrackChanges(true); wire()->addHookAfter("User::changed", null, function($event){ $what = $event->arguments("what"); $old = $event->arguments("old"); $new = $event->arguments("new"); echo "changed: " . $what . " - " . $old . " -> " . $new; });7 points
-
I would support you if any possible. Would love to have a stable shopping system on PW base (including, taxes, currencies, different porto, etc.). Maybe we could just start with making a list somewhere to collect stuff that needs to be included and stuff that could be included (like stripe checkout or stuff like this). What do you think? Btw.: I really often need to implement a shop so this would be really great. Maybe we could even raise some money if this allows you to put more work into it (Going to write you a PM)4 points
-
Hi all, I have been looking for a way to manage deployment of new sites, as well as versioning of the pw data model on sites already deployed, working with teams, etc. I've enjoyed the discussion on a few threads : https://processwire.com/talk/topic/6707-update-live-site-from-staging-server https://processwire.com/talk/topic/2975-team-development https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes but so far, I have not found what I'm looking for, so I built two tools and have put them on my newbie github site for all to use and/or peruse. I hope they are relevant to this community. They are crude and only have been exercised in my relatively finite world of Windows/apache dev. See https://github.com/jeanrajotte/schlepwire and https://github.com/jeanrajotte/upgradewire Both "apps" are not designed to be modules, integrated into pw, but rather external simple apps serving their specific purposes, possibly usable in automated build systems via curl, for example. There's a bit of a diatribe in the upgradewire README.md about the goodness of keeping the model in version-able source files, as distinct from operating the pw admin to maintain fields and templates, even if these changes are being recorded, as mindplay.dk seems to be doing. That's really the philosophical thrust behind these efforts. It's a beginning. I hope it's of interest here. Again, thank you for this superb framework and this generous community. Jean2 points
-
2 points
-
Pushover looks pretty cool. I’m currently implementing realtime functions in a PW project using http://pusher.com, totally recommend it!2 points
-
Thanks Can, glad it works for you I'm currently rewriting the module and will switch the pdf engine behind to mpdf which seems to have much better support for html. @Bacelo There are no stupid questions2 points
-
I was having a similair issue, see here: https://github.com/ryancramerdesign/ProcessWire/issues/409 But ryan fixed it and the solution worked for me.2 points
-
Here you go: https://github.com/apeisa/PaymentPaypal-deprecated If you are trying to implement this one and not feeling lucky, just ask here. While developing this I played a lot with latest pw dev and shop modules. Everything worked just like they should - so I will move them out from alpha stage.1 point
-
Super Smartypants is a ProcessWire textformatter module which adds support for languages. It also allows you to set the different Smartypants Typographer parser attributes to customize which rules apply and fixes some bugs. Super Smartypants requires the language module. Usage After installation, add /site/modules/TextformatterSuperSmartypants/smartypants.php to your language translations. To enable Super Smartypants for a language, set the Smartypants attributes field to 1 (or see below for details), otherwise to disable leave the field empty. Change default strings according to your masterful typographic knowledge. Documentation and download : https://github.com/plauclair/SuperSmartypants1 point
-
Hello community My new website is nearly finished, I used: processwire (of course) dead simple grid modules: form Builder , XML SITEMAP1 point
-
Ryan, the example page for the module throws a 404. (Forgot to publish?)1 point
-
I haven't had any need for shop since the site I build it two (or was it three) years ago. That's one reason that shop hasn't got any love from my side. I build this paypal module since it was requested so many times. It should work just fine. I would like to build some of the components again, like better shopping cart, more general payment methods, independent checkout process etc, but not sure if I have time for it (especially since the need on e-commerce had been so little on my day job).1 point
-
That is bad example you have there. For pagename you need to use $sanitizer->pageName() method. But it's also possible in newer versions to let pw handle the name field, just give a title and pw transforms it to a unique name (and adds number suffix if required).1 point
-
Changing core modules is never an option. Not even consider it temporarely. But there's plenty of ways and hooks you can change behaviour of core modules. There a couple ways to do that, in templates consider this // current viewed language $viewLang = $user->language; // clear user page cache $pages->uncache($user); // saved user lang echo wire("user")->language; // set back viewed language $user->language = $viewLang; Or there would be a ways to handle it with a simple autoload module. Since the language is set after the init() you can get the stored user language there. Then Language support sets the language on the ready() method, so you could get the currently viewed language in the ready() of your module and compare.1 point
-
Very cool and right in time! - I was just about to hacking the original code to make it work in German. Your solution, using language translation files, is VERY SMART. - Works well so far (tested with PW dev, German/English). Thank you very much for this contribution!1 point
-
Short answer: do what your site/application requires and whatever is within the limit of your server's resources. My 2 cents: One question I always ask myself when dealing with session data is whether or not I want that data to reflect the same exact information that I saw while visiting the page the next time I visit. If I revisit the page after I log out, close the browser, or hit the back button, what should that data look like? Typically, if (other) users, applications, functions, methods, etc. need to modify this data, then a session variable is out of the question for me. But if I want this data to be the same after I enter it, (ie: shopping cart information that I have added a shirt to when at work that I want to review when I get home) then that information might be alright for me to use in a session. Nonetheless, I still prefer to store only enough information concerning the session. I usually reserve session variables to hold information (user name, id, department, specific date of something important - maybe sale end date, shirt item number, etc) directly related to the user, application, or page that is being served. Then, based on those parameters, I make Processwire fetch the needed page(s) information (cost of the shirt, quantity remaining, etc) because these things are subject to change.1 point
-
This is pretty similar to how Spex works (shameless plug). It doesn't use a separate file for controllers however, the template file is used as a dual purpose: controller and initial generation.1 point
-
FieldtypeLikes is a module I've been working on (it's what is used here on the PW sites, as well as on CMSCritic). I've just been trying to find the time to finish it up so that others can use it, and hopefully can here soon. Tyssen I was thinking I could get you to beta test since you've got a more immediate need? Here's a section from the documentation which may answer some of the questions above: Likes Fieldtype for ProcessWire This Fieldtype enables you to have a "like" button that users can click on to like a particular page and have that be remembered. The fieldtype itself stores a single integer representing the number of likes each page has in total. As a result, the field can be used for the purpose of sorting pages, i.e. "most liked pages." FieldtypeLikes also adds a $session->getLikedPages(); that returns a PageArray of pages that the current session has clicked Like on. The liked pages are remembered with a cookie for up to 30 days. This enables you to have a separate page (or perhaps a sidebar on every page) that for example shows the user bookmarks of pages they liked. Before deciding whether this Fieldtype is suitable for your particular application, be sure to read the section on preventing duplicate likes. Preventing duplicate likes FieldtypeLikes is not connected with the user system, and may be used anonymously via any page on your site. The benefit is that anyone visiting can "like" things and generate a list of likes (for their own review), without having to login or create an account. That makes it much more likely that users will participate in liking pages and making use of what this module provides. The drawback to this approach is that it may be difficult to prevent one user from trying to manipulate the quantity of likes, perhaps trying to boost the rank of a page they have some interest in. Beyond cookies (which we use), in order to limit the potential for duplication, FieldtypeLikes connects likes IP addresses and remembers them (server side) for a week. As a result, there is a limit of 1-like, per page, per IP address, per week. While not ideal, this is a necessary compromise in order to have some protection for the data. Note that a very determined person could still use proxy servers or other methods of obtaining unique IP addresses. So we have also implemented some additional methods of protection. But ultimately you should always remember that if someone is determined enough, its impossible to prevent them from finding some way to manipulate the quantities of likes. As a result, do not use likes data for making decisions on hiring/firing, awards, grants or anything to be taken too seriously. That being said, I do feel the solutions we have implemented here are stronger than other anonymous rating systems I have come across, thus far. But always remember that any anonymous voting tool is open to manipulation and the results should always be take in that context, whether from this tool, or any other you've ever used or seen.1 point
-
1 point
-
There is a software limitation applied by the sanitizer. For textarea fields this limit is 16384 characters. https://processwire.com/api/variables/sanitizer/ http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-textarea-value-options/1 point
-
After all there's some quirks and stuff not coded very well. I have forked the shop module some time ago and fixed/changed minor things. I'm not sure what causing your error exactly, but seems as the session sometimes isn't set correct when the form wasn't valid or so. You could try my version of the shop module, it's the dev version that has some changes there. https://github.com/somatonic/Shop-for-ProcessWire/tree/dev Although there's more changes and additions in this version, but should be compatible and not less unstable than the apeisa version.1 point
-
new german updates for actual PW dev 2.4.5 (19 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json wire--modules--process--processtemplate--processtemplate-module.json pw-lang-de-dev-update.zip1 point
-
I don't know for sure what Reiska means either, but @apeisa told me that was apparently my Finnish name and that it means something along the lines of handyman. I had a member-title spot open, so I put it there. But if it's translating anywhere as "god of all heavens" or something like that, then I need to change it. I'm okay with being a handyman or somebody that fixes things, but need to change it reads as something egotistical.1 point
-
Continuing from my previous post in this thread about some selector enhancements available on the dev branch, we've got a couple more advanced options for use in selectors in case anyone is interested: OR-groups These let you specify multiple expressions and only one of them has to match in order for the selector to match. It's a way of saying "either this has to match OR that has to match". This is useful because selectors always assumed AND – meaning everything has to match. While you have always been able to use the pipe "|" to specify ORs for fields or values or both, the scope of it was just that field=value statement only. Now we have something new called OR-groups. These let you create multiple selector groups and only one of them has to match. You can specify OR-groups by surrounding selectors in parenthesis. An example demonstrates it best. Lets say that we wanted to find all "product" pages that were in stock, and either in a featured date range, or had a highlighted checkbox checked. Previously we would do like this with two separate find operations: $items = $pages->find("template=product, stock>0, featured_from<=today, featured_to>=today"); $items->add($pages->find("template=product, stock>0, highlighted=1")); Now we can do it in one find operation: $items = $pages->find("template=product, stock>0, (featured_from<=today, featured_to>=today), (highlighted=1)"); Above are two selectors surrounded in parenthesis. Only one of them has to match. You can specify as many of them as you want. This type of OR expression is something you couldn't previously do with selectors. Think of the parenthesis as a way of saying "this is optional". But of course, at least one of your parenthesized selectors has to match in order for the full selector to match. I'm guessing the above usage probably covers 99% of the situations where you might need it. But lets say that you want to have different combinations of OR expressions. You can create named groups that OR with each-other by specifying: foo=(selector1), bar=(selector2), foo=(selector3), bar=(selector4) In the above you'd replace "foo" and "bar" with names of your choice. And you'd replace the "selector" with any selector strings. Those foo/bar names aren't referring to fields, instead they are just named groups that you can name however you want. In that selector, at least one of the "foo" named selectors would have to match, and at least one of the "bar" named selectors would have to match. If you didn't use the foo/bar named groups here (but still used the parenthesis), then only one of the 4 selectors would be required to match. Sub-selectors Some of you are already familiar with these because it was committed to the dev branch a couple weeks ago (and I think may have been outlined elsewhere in the forums). Sub-selectors let you put a selector within a selector, enabling you to perform more complex matches that used to require you to use separate API calls. These can be used on the 'id' property of any field that maps to a page. The 'id' property is assumed when referring to a page reference or a parent, so it's not necessary to specify it unless you want to, i.e. "field" and "field.id" mean the same thing in this case. Sub-selectors are specified between [square brackets]. For example, lets say we are matching products and our product template has a "company" page field. Each company also has it's own page field where all the company locations are identified. Lets say we want to find all products that are made by a company that has more than 5 locations and at least one of those locations has "Finland" in the title. Previously we would have had to do it like this: $companies = $pages->find("template=company, locations>5, locations.title%=Finland"); $items = $pages->find("template=product, company=$companies"); That's easy enough. But now it's even simpler, as you can do it in one operation: $items = $pages->find("template=product, company=[locations>5, locations.title%=Finland]"); When you've got a "field=[value]" selector, any properties you refer to in "[value]" assume the "field", so "locations" above is referring to a property of the "company" field.1 point
-
1 point
-
@saml, what I usually do is: 01. Instal ProcessWire. 02. Delete unwanted pages. 03. Leave fields as they are. 04. Leave templates as they are. 05. Rename Fields & Templates when needed. 06. You'll see that you'll reuse every single template & field.1 point
-
Not sure about the limited browser support. I thought back in the days 56k they told better to use progressive. As it give the the feeling that it loads quicker. ( below some info from wikipedia ) These days, we want to give more more control back to CSS. Old lightbox scripts, first load the whole image, then presenting them to the screen with animation. What I see happen now a days ( more & more ) other of lightbox scripts appear. The animation delivered bij CSS & not by Javascript. And images appear on the screen directly. ( after first byte is loaded ) see magnific lightbox for example. Progressive loading is way nicer then. For mobile progressive is ideal. ---- wikipedia compression : There is also an interlaced "Progressive JPEG" format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for Progressive JPEGs is not universal; when Progressive JPEGs are received by programs that do not support them (such as versions of Internet Explorer before Windows 7)[13] the software only displays the image after it has been completely downloaded. --- Interresting read @horst. Still have to think about it. To be continued !1 point