Leaderboard

--- There might be some changes to this module in the near future! Please see this comment --- I guess we have all been there... We need to store a price to a product. "Ok, easy, let's create a new field for that in the PW backend!" might be the first thought. But then the headache starts... What about TAX? What about NET and GROSS values? And what about rounding problems when not using the correct float or decimal values ( https://processwire.com/talk/topic/7542-development-fieldtypefloat-fieldtypedecimal/ )? Meet RockPrice - a brand new (and not well tested!) module to save you from those headaches and make the UI more compact and reactive (nobody wants to calc tax/net/gross manually!). If you discover any issues or have suggestions for improvement please let me know! ? --- Download: https://github.com/BernhardBaumrock/RockPrice --- RockPrice Price Fieldtype + Inputfield for ProcessWire CMS Settings Usage The field always returns a RockPriceMulti object. This object contains an array of items and the totals vor vat, net and gross (where tax stands for the tax rate in percent and vat for the actual tax value, eg. Euros or Dollars): d($page->price); d($page->price->items->first()); API Saving field value: $page->setAndSave('price', [1000, 20]); $page->setAndSave('price', [ [1000, 20], [3000, 10], ]); Comparisons $p1 = new RockPrice(1000, 20); $p2 = new RockPrice(1000, 10); d($p1->equals($p2)); // false $m1 = new RockPriceMulti([$p1, $p2]); $m2 = new RockPriceMulti([$p1, $p2]); $m3 = new RockPriceMulti([$p2, $p1]); // flipped! d($m1->equals($m2)); // true d($m1->equals($m3)); // false d($m1->equals($m3, true)); // true (ignoring sort order)

I have now integrated the ProCache branch into the module and released it as version 1.0.0! I have tested the module on multiple sites and it's pretty stable now. But if you do run into bugs, let me know! The ProCache integration is now included, so you can clear out the ProCache page render cache alongside all other caches. Hopefully we can resolve the issue with minified assets, see the previous post. The documentation is now updated with information on all the new methods added in the previous release. Let me know if something isn't working for you!

Below is what we had changed in the MarkupRecurme.module file. As @adrian posted, our version has had a number of tweaks. So perhaps have a closer look before implementing these changes. Hopefully this helps. Line 271 $m = date('m', strtotime($date[3])); To $m = date('m', strtotime("1st " . $date[3])); AND Line 864 $m = date('m', strtotime($date[3])); $y = $date[4]; To $m = date('m', strtotime("1st " . $exclude[3])); $y = $exclude[4];

We have also noticed issues w/ Recurme dates displaying incorrectly. Similar idea as Arcturus, nothing had changed in months. What we found was the issue was triggered on a month that contained 31 days. From my re-collection it might have also affected the month by bumping it by one month. I'll post the fix that worked for us a bit later this evening.

I now have played with Custom Page Classes too. I successfully have created a cascading hierarchy for a sort of mvc system of mine: I make massive use of templates, where most of them are simple clones. I do this to have bullet-proofed identification of specific pages, but give the clients the opportunity to change title, name, and also the ID, if he once deleted a specific page and created a new one. (Template family is set to onlyOne!) All the public viewable pages are set to the same template filename (basic-page), which previously was my controller file with all the rendering stuff. Now it's content is reduced to 4 lines only, and all render stuff is included into custom page classes, whereas it now is much cleaner to read and follow compared to before, because now I can overwrite the basic render method in custom page classes for specific pages. I created a BasicPagePage as base: <?php namespace ProcessWire; class BasicPagePage extends Page { public function renderSections() { // ... } } This one is used from all other public pages and extended only where needed: <?php namespace ProcessWire; if(!class_exists('ProcessWire\BasicPagePage')) require_once(__DIR__ . '/BasicPagePage.php'); class LegalpagePage extends BasicPagePage { public function renderSections() { // override parent method here, if needed } } Here is a debug list of a few pages The basic-page.php controller now: <?php namespace ProcessWire; // load header with navbar and footer with links, hamburger, scroll-to-top item, etc. include(__DIR__ . '/includes/_header.php'); include(__DIR__ . '/includes/_footer.php'); include(__DIR__ . '/includes/_absolute-positioned-elements.php'); // call method in CustomPageClasses to render all public viewable sections of the current page $page->renderSections();

Not me. It sounds like a recipe for headache, frankly speaking. It really depends on lots of things... You should tell us more about your current site. What does it do? How complex is it? How many templates do you have now? How dynamic is it - or needs to be in the future? (for visitors and editors) How much functionality is there currently in terms of users interacting with the site (register, login, user profiles, voting / commenting....) ? Is it really just a "brochure" site (mostly static content for frontend-users, but manageable by editors) ? Or really more like a web-application? A redesign is not the same as porting content from CMS A to CMS B. If the site architecture will most likely remain, then I'd talk to the client and persuade them to allow budget to transfer the entire site in one go from Textpattern to PW (using the same frontend markup). In the long run, this would probably be more efficient. Once everything is running in PW, you could then later discuss about a redesign.

Since get_magic_quotes_gpc returns FALSE from PHP 5.4, the installer line $value = get_magic_quotes_gpc() ? stripslashes($_POST[$field]) : $_POST[$field]; safely could be replaced with $value = $_POST[$field]; (assuming you are not installing on a legacy platform)

For those who are interested, here is an explanation of why: https://www.php.net/manual/en/function.strtotime.php#92600 You need to add either the day or the year to the month to get it to work correctly. There are also some alternative fixes listed in this thread: https://stackoverflow.com/questions/3283550/convert-month-from-name-to-number

Thanks @dynweb - for some reason I hadn't noticed that. I have committed your fix. Thanks again.

Current mood

Ye. Looks like Sky News watched that before coming up with a similar analysis...or maybe just a coincidence.

Hello All, In the middle of this pandemic, I came across a citizen-science site that I think we should all consider helping out. It's called folding@home and aims to produce the largest distributed medical research computer cluster in the world, in order to solve protein folding problems, that should help develop treatments (or cures) for multiple medical conditions we all face. If you, or your company, have any spare internet connected resources, please consider joining the cluster - it's fairly easy to setup the client and connect. I'm running this on my linux laptop and hope to keep doing so. It's quite CPU intensive so you get to choose the level of resource usage it can have. For example, to control my CPU temperature. I've limited to just a single thread on an i7. Please support if you can.

Hello, I have and issue with php 7.4 about a deprecated function get_magic_quotes_gpc() used inside the installer.php...any quick fix ? Thanks in advance

Converting relative URLs to page IDs doesn't seem to work if there is more than 1 URL segment (/page1/subpage/) AND the application is NOT running in a subdirectory. I had to replace line 86 from FieldtypeAssistedURL.module $urlPage = "/" . str_replace($this->wire('config')->urls->root, "", $urlParts[0]); with if($this->wire('config')->urls->root !== '/') { $urlPage = "/" . str_replace($this->wire('config')->urls->root, "", $urlParts[0]); } else { $urlPage = $urlParts[0]; } to make it work. Am I missing something?

Remember that version you are using not only has this fix, but lots of other changes for other bugs as well. Maybe it's time to post that version in its entirety somewhere - obviously with no support or warranty, but perhaps a repo that others could issue PRs against? Then again, I honestly think the entire storage and retrieval side of this module needs to be rebuilt from scratch. the inputfield is really pretty nice, but the rest is unfortunately very cumbersome and buggy. Of course, this is not an easy thing to get right, so I am not meaning to be too critical ?

What version did you update from? I think it hasn't been possible to set access controls on fieldsets for some time, maybe years. I think there might be a couple of reasons for why you can't set access controls on fieldsets: 1. Edit access (in Page Edit) for a fieldset is meaningless because a fieldset doesn't store any user-editable data. 2. Generally speaking fields do not "know" that they belong to a fieldset. You can run your own logic like this... ...but there is no simple property of a field A that indicates that it is within fieldset B. So setting view/edit access on a fieldset doesn't actually set view/edit access for fields within that fieldset. Back when it was possible to set access controls on a fieldset it might have appeared that there was access control in that maybe the inputfields didn't get rendered, but I doubt that this was proper access control/security on the fields within the fieldset. So my guess is that Ryan removed that option so devs wouldn't get the wrong impression that they are setting access control on fields by setting it on a parent fieldset. So I think your options are... 1. Set access control on the fields within your fieldset. 2. So long as you know and are comfortable with the fact that it isn't proper access control, you could remove the fieldset using a hook: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function (HookEvent $event) { /* @var InputfieldWrapper $wrapper */ $wrapper = $event->return; // Do some test based on roles if($event->wire('user')->hasRole('some_role')) { // Remove fieldset $fs = $wrapper->getChildByName('your_fieldset_name'); $wrapper->remove($fs); } });

v0.1.1 released with support for Repeaters and comma as decimal separator. Thanks @David Karich!

I've used this library with success to import products or update them regularly like on a cron job: https://github.com/donutdan4114/shopify Takes care of rate throttling too which is nice!

@MoritzLost Thank you! I really appreciate your help and advice here. This all sounds good. I'll begin!

I would consider how other systems work out the mapping of ragged hierarchies - where you store a hierarchy level in addition to the ancestors and children relationships. Having a two dimensional structures like this enables you to manage granularity level control as well as lineage control. It becomes trivial to isolate branch grouping based on a limit of the lineage and level - say less than three. Alternatively, you can also build queries that select peers across a given landscape. For example, if local heroes of a klan that is a subfaction of a race on a given world, you can list them alongside heroes that are also part of major clans without internal divisions, or even immortal heroes without lineage or clan that live on a mountaintop on a continent. Each 'level' number represents a granularity level, not necessarily a power, quality or quantity level. The nice thing about this method is that it allows you to 'skip' levels while still retaining lineage integrity if you so choose. Here's an example of building such a data structure for an unrelated BI tool, but I think you will understand the design pattern. Perhaps this is what you are looking for: https://www.dundas.com/support/learning/documentation/analyze-data/create-a-ragged-hierarchy

I needed to create some Fields and Templates via API and it was always a pain to get the right settings (like columwith, field context settings and so on). With the brand new (and ALPHA) RockSVN Module you can create your fields via the backend and then show a diff of your changes. Please see the comments on top of the module for todos and limitations. I'm not totally happy with the diff tool, so if anybody knows a better one or knows ho to change the behaviour to line-based diff (that would be better in this case i guess) feel free to comment. As @ryan is using the same diff tool in ProDrafts i guess there's not too much hope... anyway - i think the module can be a big timesaver and also help you to keep track of changes - an often requested feature and maybe also a good companion for @LostKobrakai s Migrations module! (Benjamin, jump in ) The module will create some Fields, Templates and Pages for you. All properly tagged and hidden, so it should not mess up things more than needed. Caution: Currently the module removes all those pages, templates and fields on uninstall! Requires my new basemodule called RockTools RockSVN.zip

This markup actually belongs to InputfieldWrapper rather than individual inputfield renders. There is the InputfieldWrapper::setMarkup method that you can use to customise the markup that is rendered by InputfieldWrapper. See the defaultMarkup property as a starting point for what can be customised: /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "<ul {attrs}>{out}</ul>", 'item' => "<li {attrs}>{out}</li>", 'item_label' => "<label class='InputfieldHeader ui-widget-header{class}' for='{for}'>{out}</label>", 'item_label_hidden' => "<label class='InputfieldHeader InputfieldHeaderHidden ui-widget-header{class}'><span>{out}</span></label>", 'item_content' => "<div class='InputfieldContent ui-widget-content{class}'>{out}</div>", 'item_error' => "<p class='InputfieldError ui-state-error'><i class='fa fa-fw fa-flash'></i><span>{out}</span></p>", 'item_description' => "<p class='description'>{out}</p>", 'item_head' => "<h2>{out}</h2>", 'item_notes' => "<p class='notes'>{out}</p>", 'item_detail' => "<p class='detail'>{out}</p>", 'item_icon' => "<i class='fa fa-fw fa-{name}'></i> ", 'item_toggle' => "<i class='toggle-icon fa fa-fw fa-angle-down' data-to='fa-angle-down fa-angle-right'></i>", // ALSO: // InputfieldAnything => array( any of the properties above to override on a per-Inputifeld basis) ); But this applies to the whole InputfieldWrapper. In terms of making it more targeted you can set markup for individual inputfield types by using the inputfield class name as a key: $wrapper->setMarkup([ 'InputfieldText' => [ 'item' => '<li {attrs}><p>Markup before</p>{out}<p>Markup after</p></li>', ], ]); But you can't target individual inputfields by name or something like that. LoginRegisterPro has a similar setMarkup() method but has the added feature of letting you use "name=some_inputfield_name" as a key: https://processwire.com/store/login-register-pro/docs/#customizing-markup-and-or-class-attributes-html It would be cool if a feature like that was added to the core InputfieldWrapper::setMarkup method.

Hi all, Apologies for the very loud silence! I hope to elaborate more on this a bit later. However, rather than keep people guessing, I'll write something short. I have been working my fingers to the bone to release a beta by spring 2020. I suppose it hasn't gone unnoticed that I rarely post in the forums at large these days. This is because I am dedicating nearly all my time to Padloper. The plan was to start early beta testing in mid-April 2020. This was largely on track. Like many of us, maybe most of us in the forums, we have all been affected in one way or another by the current situation in the world. This has thrown a monkey wrench in the works. I have had to readjust how I work, albeit my productivity taking a hit. I wish I could properly 'guesstimate' how much delay this is going to cause but it will just be futile. On the other hand, I appreciate that you have been waiting for a relatively long time for this release. I want to reassure you that I am not just kicking the can down the road. Maybe I should have been showing you more screenshots of progress but currently, that would just eat further into my limited time. Thanks for reading, and hopefully, your patience. Cheers.

See the two posts above yours ?. Currently, this is not possible if using the render() method but I have added it to my todo list.

Another problem with RestAPI. When loading large files, an error occurs. In the backend everything is fine, a 300 MB file is loaded normally. The problem only occurs when testing through Insomnia or Postman with files larger than 15 mb. We managed to solve the problem. It is necessary to include AJAX in the file properties. $ul = wire(new WireUpload($formName)); $ul->setValidExtensions(['mp4', 'avi', '3gp']); $ul->setMaxFiles(1); $ul->setMaxFileSize(100 * 1000000); // 100 MB $ul->setOverwrite(true); $ul->setDestinationPath($p_path); $ul->setLowercase(true); $ul->setAllowAjax(true); $files = $ul->execute();

@thomasaull It seems I found what was the mistake. It was necessary to transfer the dispatch from Insomnia to the multipart format and set the file name. After that, in the $_FILES variable you can find all the data to get the file. $_FILES Array( [upfile]=>Array( [name]=>hot-pizza.jpeg [type]=>image/jpeg [tmp_name]=>/localhost/tmp/phptAUnX5 [error]=>0 [size]=>65639 ) )

One thing to remember with Processwire is that while the default behaviour, and that of most built in fieldtypes is to use one table per field, like with most things, Processwire is incredibly flexible, so if you have a use case where a single table with multiple fields will be a more efficient way to store and access data, Processwire supports that too through custom field types, and indeed their are some built in fieldtypes that actually do work this way, such as map markers. Profields also includes a table fieldtype which as it sounds, is a database table with multiple fields. It takes a bit of work to write a module to provide a custom fieldtype but there are examples in the modules directory such as fieldtype Events which is specifically intended as an example of how to make a fieldtype that corresponds to multiple database fields. https://modules.processwire.com/modules/fieldtype-events/ In answer to the question, "Is the Processwire database structure scalable", I'd say that's entirely up to the developer, as you can really choose whatever database structure you like, just it takes a bit more work if you want to store multiple fields per table, and usually the built-in fieldtypes and default behaviour works fine. Where I have noticed there can be a little bit of a performance hit is doing a large import from CSV where each field from the CSV file results in a separate insert operation to a different table, whereas with a traditional database table with multiple fields would result in just a single insert operation per record, and potentially fewer indexes to update as well. If you're doing single page additions via the backend, via user interaction, Processwire is plenty fast enough, and there are performance gains to be had at the read level if you don't need to read every single field from a page every time it's accessed in front end templates, eg building a menu, you probably only want title and url, so reading the entire page content as well is unnecessary overhead, but if the content is in a separate table, and you don't access it, you don't have that overhead. There are always performance tradeoffs, but I think Processwire has struck a good balance. A default that works well for most people, but the means to do things differently if you really need to.

On the other hand, "flat", that is non-normalized tables, scale only somewhat. Where they don't scale well is in update performance, so if a site is highly dynamic, updates create massive locks and those locks impact the frontend too. Then, if a CMS uses non-normalized tables, multi-valued and complex field contents will have to be serialized and de-serialized to fit into their column. That's only fine until you want to search for it. In that case, things get ugly, and if that search can even be implemented, it will be a much worse performance hog than ten extra field tables in PW. The web server question "does it scale?" is usually not answered by database statistics. It's answered by a concise design that allows for good, hierarchical and atomic caching strategies. If a site is designed with that in mind (and even sometimes when it isn't), performance can easily be improved. I like to take our corporate intranet as an example, with 12000 active pages, now 125 templates, 28 repeaters, 35 site modules, 220 additional php scripts and everything a good book on website speed basics tells you not to do ? We have around 1000 users who use it daily, and a good number of them have a few auto refresh pages loading every 2 minutes. I'm running opcache, use processwire's $cache interface to populate recurring, user dependent patterns in some fields and have a small home-written module that uses memcache to store and refresh data that would otherwise be retrieved from external systems with each call. First time page load including fonts, styles and a healthy collection of scripts is about 5 seconds. Times to page view for consecutive visits to the site are almost always below 2.5 seconds. Everything runs on one single server, including the database, and there's no caching proxy in front of it. That's on PW 3.0.125. I'm currently in the process of upgrading to latest IIS, latest PW stable and latest PHP. My first impression is that I'll probably get the time-to-view reliably below 2 seconds with a bit of tuning.

Visual Page Selector Released 31 March 2016 https://processwireshop.pw/plugins/visual-page-selector/ As of 04 January 2018 ProcessWire versions earlier than 3.x are not supported ******************************************************* ORIGINAL POST ******************************************************* Introducing VPS, a commercial visual page field selector. This is a pre-sale closed-beta version. This post is WIP and will be updated now and then. ############################ Many ProcessWire users use the 'one image per page' principle to manage and reuse images across their sites. This works fine. However, for site editors who mainly work with images, especially for larger sites, it is sometimes difficult to remember the pages where particular images reside. This module helps to solve this challenge. Harnessing the awesomeness that is ProcessWire, VPS provides a rich editing experience, enabling editors to search for, view, select, add, remove and delete page-images easily, in an easy to use and friendly interface. ProcessWire Lister is the workhorse behind the lightning-fast searches. Editors will be able to search for images by their descriptions, names, partial names, page names, templates, etc. Current Features Single-image mode Full search Batch add/Remove/Delete Image/Delete Page in page fields Image Browser Selectable pages as per page field settings + Lister filters Grid and List View Draggable sorting Responsive (almost fully ..iframes!) Planned Features Multi-image mode (there are times you want to group similar images in multi-image field in one page; e.g. the back, front and side of a car photo) Configurable CSS on the fly resizing vs real image resizing (image resizing can quickly hog memory) Other as per feedback from beta testing FAQs When will this be available? Soon. How much will it cost? Reasonably priced. Announcement soon. Where will I be able to buy this from? At all fine stores that stock quality ProcessWire products Do we really need another page field/inputfield select? See links below. What type of licenses will be available? Soon to be announced. Can I beta test this? Thanks for the interest but all available slots have been taken. Video (excuse the video quality please - too many takes....) Screens Previous Discussions https://processwire.com/talk/topic/10927-wishlist-select-pages-by-thumbnail/ https://processwire.com/talk/topic/4330-get-image-from-other-pages-via-images-field/ https://processwire.com/talk/topic/417-extending-image-field/?p=6982 https://processwire.com/talk/topic/7073-profield-table-and-gallery/ https://processwire.com/talk/topic/3200-image-management-concerns-is-processwire-suitable-for-me/ https://processwire.com/talk/topic/425-file-manager/ https://processwire.com/talk/topic/10763-asset-manager-asset-selector/

Note that if you have an SQL query that you are finding difficult to turn into an equivalent selector then you do have the option of getting the page IDs via SQL and then loading those page IDs. An example (not that this is difficult to do as a selector)... $sql = "SELECT pages.id FROM `pages` JOIN field_title AS field_title ON field_title.pages_id=pages.id AND (field_title.data LIKE '%a%') WHERE (pages.templates_id=59) AND (pages.status<1024)"; $query = $database->query($sql); $ids = $query->fetchAll(\PDO::FETCH_COLUMN); $items = $pages->getById($ids);

@Soma Yeah this is my issue with Vue.JS - I use Vue.JS often for two way data-binding which is amazing to be able to easily update content and do visual changes to the site based on those updates. For example adding something to a basket. It's much easier with Vue than jQuery or JavaScript. My issue with Vue is exactly that. You can use it just on a component basis or you can use it to render your entire UI. To me it just doesn't make sense to use it to render an entire UI with a website. A web app sure, but a website it's often overkill and introduces that exact problem. You can introduce server side rendering of Vue with Nuxt but then it just seems like another layer of 'over complication'. I personally stopped using Vue for websites unless I absolutely needed two way binding. It just didn't make sense and the extra complication of implementing it such as having to convert everything from ProcessWire into a JSON feed. EDIT: Noticed this post still gets likes, so what's changed since then? AlpineJS. AlpineJS is a solution to this exact problem, worth a look for anyone wanting to do some cool UI stuff without including all of Vue features and overhead.

You could always use an bootstrap script, which does connect to the Textpattern database, reads the data by mysql queries and then use the processwire api to fill those data into the pages you need.