Leaderboard

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.

...or you can use this small module that (with a lot of nicked code from ProcessField) adds the functionality to the Template list: https://github.com/BitPoet/TemplateTagsEditList Best try it out on a copy of the site though, I haven't tested it much yet. Anyway...have fun ? (I'm soon going to use this a lot myself to clean up a few really complex sites...)

UPDATE 2020-01-30 SnipWire 0.8.0 (beta) first public release! It is done! After almost 1 year of hard work and a lot of help from the usual suspects I just released the first public version! Please note that this is still a beta so please test, test, test before you use this plugin in a real project. The module can be loaded via PW modules directory (just submitted - in review I think) or directly via GitHub. More infos will be added soon ...

I just submitted my first module to the PW modules directory. The module is a full featured e-commerce module but I couldn't find a corresponding category there. May I suggest that a responsible person add a new category "e-commerce" (or something similar)?

You can use the API: $tpl = $templates->get('service'); $tpl->tags = "foo bar something else"; $tpl->save(); or for multiple templates, just create an array with tpl-names, and do a foreach()

This is an update about how it's been running blog sites using ProcessWire. I hope it's OK for me to post in this category even though I've already showcased my sites awhile back. I thought it would be helpful for people to get a feel for what it's like to use ProcessWire on an ongoing basis for blogging. Often people talk about the development of a site, but it's not quite as often that we hear about the ongoing running of a PW site and how the PW API influences that, which is what I'll cover here. As background, we at The GrayFly Group own and run the blogs goodkidsclothes.com and flipfall.com. The development of these PW sites has been covered in a showcase thread for GoodKidsClothes and another for FlipFall. Here are some of the unique experiences I've had running these two sites. "Running" covers everything from coding and making modifications to the templates, to writing our articles, to interacting with ad partners or with others seeking us out for something related to one of those sites. So this is a different experience from agencies who develop for others; we develop for ourselves. As background, the main traffic to the websites comes from organic search results. Income from sites is from affiliate marketing and advertisements. GoodKidsClothes PW experience: "to think it is to do it." For GoodKidsClothes.com, one of the things we noticed was that if we could think it, we could do it, thanks to the easy-to-use PW API. The need for a change Here is a concrete example of what I mean: we noticed that many people would enter the site on an older article (e.g. via a search result). However, we continually put out a lot of time-sensitive information, e.g. a style guide, a piece of news relating to a change in a children's clothing company, etc. I didn't want people to miss out on this, yet many were, because after reading their entry page, they'd leave. They had no idea (unless they clicked on the link to home page) that there was another article that could be of value to them. All too often, by the time people learned about that new article via search results, they'd be too late for the news to be relevant - in fact, it wouldn't even be the newest article anymore by that point. The solution So, using the PW API, we modified the article template so that if someone was reading any article that was not the most recent article, then at the end of what they're reading, they'd see a small section highlighting the most recent article. Here is a screenshot: As you can see above, our newest article is highlighted immediately below the article they're reading, unless of course they are already reading the newest article. In the case shown above, the newest article (recipe-related) did not happen to be time-sensitive, but in most cases that article would be time-sensitive, so that's why we made this change. To make the change we simply used the PW API to query what the latest article was and store its identity in a variable - those sorts of queries we set up in _init.php. Then we modified the article template such that if the current page was not the latest article, to include the featured box that you see above. Another need for a change You'll also notice links in boxes above and below where the featured article box is. These are ads (they blend OK right?!) These ads brought another problem to our attention: we'd put the ads blocks on all articles equally. However, in the case of the most recent article, often the most recent article would usually have a time-sensitive offer or some other call to action e.g. signing up for our newsletter (well, not in the case of the recipe article above, but in most cases the latest article would have something we prefer the reader to do). We didn't then want our readers to get distracted by the ads and either leave the site, or click on an ad and click away from the site, instead of doing whatever the call to action is. The solution Again using the ProcessWire API, we modified the "article" template so that there was conditional logic on the ads: if the current page is not the latest article, include the ad code (otherwise no ads). This mean no ads were seen on the most recent article, allowing for less distractions to the reader on time-sensitive articles and more likelihood of them following through on the call to action. Conclusion for GoodKidsClothes We were able to make all these changes within minutes of thinking of them! In-house, without a ton of knowledge of programming, thanks to the awesome ProcessWire API. We actually made all those changes live, i.e. going in there and making changes to the code of the site as its running live. Yes, we had backups of the entire site and we always first save a copy of the template file under a different name (usually prefixing it with OLD_ ) before modifying the live version. This is how helpful ProcessWire is. We can make changes that benefit our site and make them in-house as we think of them. If this was done under some other CMS, we would be unable to make those changes without either a) hiring a developer or b) training up in whatever the other CMS is to make the changes in-house. Either way, it would take considerably more time to do anything. So, despite not having a formal programming background, we now have a very "nimble" site that we can adapt as needed to changes that we desire, within minutes of thinking of the change we need, with only needing to know a little PHP, html, and CSS, just the very basics, and looking up the PW API. FlipFall PW experience: "the answer is yes." In the case of FlipFall, there have been times when a potential ad partner asks a question like "can you put different ads on different categories?" or other things. Sometimes they are questions I ask myself of the website "Can we do A/B testing of different ads; i.e. show a certain ad block 50% of the time totally randomly and another ad block the other 50% of the time?" "How about ads from this company some of the time and a different company other times?" The answer is always "yes." Coming from other CMS's (that I used but did not program with) I used to brace myself a bit if I saw an email that asked "Can you....?" but now thanks to ProcessWire I don't have that bracing reaction any more. So long as I can think of a way to do it (and so far I always have, thanks to the PW API), I can say "Yes we can." More to the point, I can actually say "Yes, we can make those changes in-house within [whatever brief timeframe I think it will be]" instead of having to be vague about timeframes because of needing a developer. So I no longer worry about "Can you ...?" questions because the answer is yes. Overall conclusions ProcessWire is a superb CMS for those who own and run a site. The PW API makes it easy to make changes to the look and functionality of the site as needed. Such modifications wouldn't easily be possible on alternative CMS's that are heavily "theme-based".

Here's a small new module that adds a "Manage tags" button to the template list, just like the field list already has. Easily add, remove and change tags for your templates. https://github.com/BitPoet/TemplateTagsEditList

Ryan will review. In the meantime, you can access and edit it at: https://modules.processwire.com/modules/snip-wire/

Hi @teppo, I've not used <picture> myself, so will need time to do a bit of research. Off the top of my head though, I do feel that this module wouldn't necessarily be the best place for it. When I get a chance I'll have a think through the implications. Cheers, Chris

as far as I can tell Templates do not support tagging in the same way as the fields, there is no "manage tags" button, and no executeTags() method in ProcessTemplate.

Correct me if I am wrong, but I don't think there is an "easy" way to change the icon itself, unless you went with custom js to find the icon and switch out the class names (font awesome) to something you desired. The only other option I see is to delve into custom theme building. So in your admin.php file (site/templates), add the following lines above the required controller: $modules->get('JqueryCore'); $config->scripts->add($config->urls->templates . "scripts/your-js-file.js"); Next, in your custom javascript file (which I would just put in your scripts folder), you could do something like: $(document).ready(function () { $('.uk-breadcrumb > li > a.pw-panel > i').removeClass('fa-tree').addClass('fa-telegram') }); In the above code, it will change it to the telegram icon. Simply change out the icon to any fontawesome 4 (I believe) icon you wish. The only issue with this is you will briefly see the original tree icon until the document is ready. I could not get it working without the document.ready function. Perhaps someone knows a way around this.

I have not truly vetted the plugin, but there is this official plugin via CKEditor. It let me select from various protocols and has an "other" selection. I was able to successfully use the file:// protocol inside the href without it getting stripped.

Have you tried the Migrations module? It's a bit of overhead to create migrations classes instead of using the admin UI, but it's nice to have reproducible template and field changes across all environments. Then you'd only need to mirror or sync /sites/assets/files/ and /site/templates/ somehow.

Hmm. This is a tricky one as it is made up of two parts: Paying a fraction (instalment) of the total cost Future payment (aka recurring payment) Both are tricky, but especially #2. #1 is partly achievable by raising an invoice using manual order creation. The order will be manually marked as complete once the total has been paid. Automating the process may not be an easy task. I'd have to think about it more. # 2 If this means storing user card details, then no; we are not going down that route. However, if it means using payment providers' subscription/recurring payments services, then it is probably doable. The payment providers API is there. Something else to think about, but for future versions. Currently none of these features are in the plan, but I'll have a think. I will probably need reminding though :-).

@prestoav I needed something similar however I did not want to give the front end users all the features available in the PW CKEditor menu. It was more difficult for me to reduce the feature set than start afresh for the front end and I chose TinyMCE over CKEditor. In the form, I created a textarea field with no textformatters and a limit of 5000 characters. In my template: <script src="<?=$config->urls->templates?>scripts/tinymce/tinymce.min.js"></script> <script> // NoMinify tinymce.init({ selector: '#Inputfield_introduction', height: 300, menubar: false, plugins: [ 'advlist autolink lists link image charmap print preview anchor', 'searchreplace visualblocks code fullscreen', 'insertdatetime media table paste code help wordcount' ], toolbar: 'undo redo | formatselect | bold italic backcolor | alignleft aligncenter alignright alignjustify | bullist numlist outdent indent | removeformat | help', setup: function(ed) { var maxlength = parseInt($("#" + (ed.id)).attr("maxlength")); var count = 0; ed.on("keydown", function (e) { count++; if (count > maxlength) { alert("You have reached the character limit"); e.stopPropagation(); return false; } }) } }); </script> And the end result on the front end: Data is saved correctly in the DB and all good. PS: If anyone tries to add in a sneaky <script>, it throws 403 Forbidden error

UPDATE 2020-01-28 I just added the Snipcart "Custom Order Fields" feature! Thank's @Noboru & @d'Hinnisdaël & @szabesz for your help and hints! Custom order fields can be added/configured by editing a hidden config page under Admin > Setup > SnipWire > Custom Cart Fields. The corresponding template/page/field resources are preinstalled by SnipWire installer. If you update to the new module versions, those resources will be added too! The config page has a single textarea field where you can add the configuration strings for your custom cart fields: (multi language support is also available) ... can also be edited and enabled/disabled from within SnipWire module config. The config from the screenshot above leads to the custom step "Order Info" in checkout process: The Snipcart docs for Custom Order Fields (v 2.0) can be read here: https://docs.snipcart.com/v2/configuration/custom-fields Next step is to implement custom product fields! When this is done, I'll release the first official version. SnipWire will then be added to the ProcessWire module directory (as far as @ryan accepts it).

Solved by @flydev! Turns out I had the wrong permissions set for the top-level directory. Nothing to do with .htaccess as it turns out! All content of /var/www/html was attached to root's group. So a simple chown -R www-data:www-data /var/www/html did the trick. I just want to say that I'm so thankful for how helpful the ProcessWire dev community is and will make sure to pay it forward!