Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/06/2021 in all areas

  1. I see there is a number of topics that are actively discussed in this thread. Maybe we could make a subforum with the selected 2021 roadmap features to be discussed with dedicated working groups? Not to loose the momentum we got here in this thread) And to nurture that community participation in the future of our beloved ProcessWire. I see these: A strategy/fieldtype for creating rich content. Making admin themes be extendable and/or adding features to them like a sidebar (might be it could be accomplished as an extension?) External API / using PW as a headless system out of the box. Central media/image manager for reusing images across pages Support for different file storages for image like Flysystem Growing popularity of PW (without sacrificing stability of course). Showing github contributions and such. Implementing admin forms in the frontend / making a limited admin for non superusers (pushing this as I am personally interested)) ...seven is a great number to deal with, but certainly there could be more)))
    4 points
  2. Hey @flydev 👊🏻. Now that half a year has passed, any news ? A release date? Will this fieldtype be free or paid?
    4 points
  3. Below are the style overrides that I apply, mostly just spacing changes and fixes for things that looked off to me. There might be one or two things in there that don't make sense out of context because I'm also loading some custom JS to change the icon of the "user" menu and have the primary link be to the site frontend rather than the user profile. The problem is that if you create the minimal module that extends AdminThemeUikit (i.e. just the class declaration and the getModuleInfo method) then what you want to see is everything displaying as per AdminThemeUikit. Then you would add custom CSS/JS and override any AdminThemeUikit/AdminThemeFramework methods as needed. But what you actually see is this: If that is expected then it would be helpful to have some documentation or a blog post about how to go about extending AdminThemeUikit, or what file structure is needed for a full custom admin theme if anybody is game enough to try that. The only hookable methods that I can see are AdminThemeUikit:renderBreadcrumbs and AdminThemeFramework::getUserNavArray. So for the thing I mentioned (manipulating menus) you can only customise the "user" menu. It's not possible to dynamically add items to the Pages, Setup, Modules or Access menus without resorting to JS hacks like AdminOnSteroids does. And on the topic of the admin menus, the caching is a bit of a pain and doesn't measurably improve performance according to my tests: https://github.com/processwire/processwire-requests/issues/268#issuecomment-464200684 Another menu related request: https://github.com/processwire/processwire-requests/issues/189 What would be great is if for each major part of the admin theme layout (e.g. header, menus, top of content, bottom of content, footer) there was some hookable method so it was possible to inject custom markup at those points.
    4 points
  4. Thanks Ryan - this sounds like exactly what we need - it would be great if authors of all alternate theme modules could update to use this approach - currently they are all subject to getting behind the core themes in terms of functionality. I wonder though if perhaps it's time to set up a "base" theme that handles all the basic functionality / layout of the admin and have Uikit extend that. Of course the default theme and Reno could also be modified to extend it, although I expect doing that would be a waste of effort as I think most people are using the Uikit theme. Regardless, I do think it's time it became the default theme way one or another.
    3 points
  5. @szabesz Isn't there already a decimal fieldtype available? I thought there was already a solution for that need, though I've never had the need for a decimal fieldtype so I've not tried it and don't know if it's lacking anything. I guess I figure the ideal situation for something like this is if it's developed by someone that also uses it. But if there's not one available, or what's available is lacking in some way, or not maintained, etc., then I could look into it. Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo).
    3 points
  6. @Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this: File: /site/modules/AdminThemeTest/AdminThemeTest.module <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } } You'll also need this file in the same directory: File: /site/modules/AdminThemeTest/controller.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); require($config->paths->core . "admin.php"); The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though): <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } public function renderExtraMarkup($for) { $out = parent::renderExtraMarkup($for); if($for === 'head') { $out .= "<style type='text/css'>" . "#pw-content-head h1 { font-size: 24px }" . "</style>"; } return $out; } }
    3 points
  7. @ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.
    3 points
  8. That would be awesome. The one who developed that module has been away for more that two years. @arjen stated that he is happy to maintain his fork but it is not an ideal situation that I always have to point people to Arjens's fork instead of the no longer maintained module in the Directory. Anyway, it is a common need and as far as I know the core concept is that ProcessWire should support features most of us need. I think this is such a thing, based on the popularity of my request: https://github.com/processwire/processwire-requests/issues/126 where there is already a discussion in which others explain why they think it should be part of ProcessWire.
    2 points
  9. Not trying to diminish your request for this to be in the core, but just an FYI that AdminOnSteroids supports this. The other thing it supports which is pretty much the main reason I use it is so that the buttons show on full row hover - I can't stand using the admin without that feature - it reduces mouse movement but so much 🙂
    2 points
  10. Unfortunately, PW only supports one dimension for arrays when using the API to process data. There's been some discussion on this topic at GitHub: https://github.com/processwire/processwire-issues/issues/387
    2 points
  11. Some great discussions going on here, I literally don't know where to start with the likes, quoting and commenting. For me, I have always understood that ProcessWire has been largely for Ryan and his clients, but the massive feature set has always worked for my needs (and many more peoples needs). Luckily for me when I have been looking to do certain things it has always popped up in the core a month or so later and the pro modules help me achieve what I need to with ease (albeit it in a different way to other systems*). The simple fact is, other systems* have file managers and other systems* now have their own take on content builders. Most clients have a previous system* which will definitely have a file manager, and clients will soon be asking for content builders. Yes I can use a module for the files and repeater matrix for content builders, but as Ryan said surely we already have a great starting foundation for these 2 features to break out into something awesome. Whilst a ProcessWire version doesn't have to be exactly the same and I have no doubt that less will be more compared to the theme monster that is WordPress, I think without them I am going to find it increasingly difficult to sway bigger clients decisions when their staff are managing the updates and have used other systems*. * I tried not to spray WordPress all over my post, but being in the UK, this is what a huge percentage of people have heard of, use, and I migrate them over from. And of course they love the end product, but I do think a file manager and content builder are the 2 things I need for my sales process going into 2021.
    2 points
  12. At least the most popular requests should be reconsidered I think, such as: https://github.com/processwire/processwire-requests/issues/126 It is hard to build ecommecre solution without adequate precisions of numbers. In countries like Hungary, a price of 1000000.00+ is quite common. The limit of 9999.99 is _always_ an issue.
    2 points
  13. Regarding the ability to modify the admin theme... Look at Admin Theme Boss (the only custom admin theme I have ever seen used for PW3) thread, and at this particular post to start with. @Noel Bossis probably the man to talk about making extending Admin Theme Uikit a better experience. As well as @bernhardwith his RockSkinUikit and @tpr, who knows the admin inside out making his AdminOnSteroids. And @Robin S is already here, of course)
    2 points
  14. Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.
    2 points
  15. Hello community! I want to share a new module I've been working on that I think could be a big boost for multi-language ProcessWire sites. Some background, I was looking for a way for our company website to be efficiently translated as working with human translators was pretty laborious and a lack of updating content created a divergence between languages. I, and several other devs here, have talked about translation integrations and have recognized the power that DeepL has. DeepL is an AI deep learning powered service that delivers translation quality beyond any automated service available. After access to the API was opened up to the US, I built Fluency, a DeepL translation integration for ProcessWire. Fluency brings automated translation to every multi-language field in the admin, and also provides a translation tool allowing the user to translate their text to any language without it being inside a template's field. With Fluency you can: Translate any plain textarea or text input Translate any CKEditor content (yes, with markup) Translate page names for fully localized URLs on every page Translate your in-template translation function wrapped strings Translate modules Fluency is free, and now so is DeepL Since this module was first built DeepL has introduced free Developer accounts that allow anyone to start using Fluency at zero cost and beginning with the version 0.3.0 release Fluency now supports free DeepL accounts. As of June 2021 DeepL supports translation to 26 languages and continues to offer more! Installation and usage is completely plug and play. Whether you're building a new multi-language site, need to update a site to multi-language, or simply want to stop manually translating a site and make any language a one-click deal, it could not be easier to do it. Fluency works by having you match the languages configured in ProcessWIre to DeepL's. You can have your site translating to any or all of the languages DeepL translates to in minutes (quite literally). Let's break out the screenshots... When the default language tab is shown, a message is displayed to let users know that translation is available. Clicking on each tab shows a link that says "Translate from English". Clicking it shows an animated overlay with the word "Translating..." cycling through each language and a light gradient shift. Have a CKEditor field? All good. Fluency will translated it and use DeepL's ability to translate text within HTML tags. CKEditor fields can be translated as easily and accurately as text/textarea fields. Repeaters and AJAX created fields also have translation enabled thanks to a JavaScript MutationObserver that searches for multi-language fields and adds translation as they're inserted into the DOM. If there's a multi-language field on the page, it will have translation added. Same goes for image description fields. Multi-language SEO friendly images are good to go. Creating a new page from one of your templates? Translate your title, and also translate your page name for native language URLs. (Not available for Russian, Chinese, or Japanese languages due to URL limitations). These can be changed in the "Settings" tab for any page as well so whether you're translating new pages or existing pages, you control the URLs everywhere. Language configuration pages are no different. Translate the names of your languages and search for both Site Translation Files (including all of your modules) Translate all of the static text in your templates as well. Notice that the placeholders are retained. DeepL is pretty good at recognizing and keeping non-translatable strings like that. If it is changed, it's easy to fix manually. Fluency adds a "Translate" item to the CMS header. When clicked this opens up a modal with a full translation tool that lets the user translate any language to any language. No need to leave the admin if you need to translate content from a secondary language back to the default ProcessWire language. There is also a button to get the current API usage statistics. DeepL account owners can set billing limitations via character count to control costs. This may help larger sites or sites being retrofitted keep an eye on their usage. Fluency can be used by users having roles given the fluency-translate permission. It couldn't be easier to add Fluency to your new or existing website. Simply add your API key and you're shown what languages are currently available for translation from/to as provided by DeepL. This list and all configuration options are taken live from the API so when DeepL releases new languages you can add them to your site without any work. No module updates, just an easy configuration. Just match the language you configured in ProcessWire to the DeepL language you want it to be associated with and you're done. Fluency also allows you to create a list of words/phrases that will not be translated which can prevent items such as brands and company names from being translated when they shouldn't Limitations: No "translate page" - Translating multiple fields can be done by clicking multiple translation links on multiple fields at once but engineering a "one click page translate" is not feasible from a user experience standpoint. The time it takes to translate one field can be a second or two, but cumulatively that may take much longer (CKEditor fields are slower than plain text fields). There may be a workaround in the future but it isn't currently on the roadmap. No "translate site" - Same thing goes for translating an entire website at once. It would be great, but it would be a very intense process and take a very (very) long time. There may be a workaround in the future but it isn't on the roadmap. No current support for Inline CKEditor fields - Handling for CKEditor on-demand hasn't been implemented yet, this is planned for a future release though and can be done. I just forgot about it because I've never really used that feature personally.. Alpha release - This module is in alpha. Releases should be stable and usable, but there may be edge case issues. Test the module thoroughly and please report any bugs via a Github issue on the repository or respond here. Please note that the browser plugin for Grammarly conflicts with Fluency (as it does with many web applications). To address this issue it is recommended that you disable Grammarly when using Fluency, or open the admin to edit pages in a private window where Grammarly may not be loaded. This is an issue that may not have a resolution as creating a workaround may not be possible. If you have insight as to how this may be solved please visit the Github page and file a bugfix ticket. Requirements: ProcessWire 3.0+ UIKit Admin Theme That's Fluency in a nutshell. A core effort in this module is to create it so that there is nothing DeepL related hard-coded in that would require updating it when DeepL offers new languages. I would like this to be a future-friendly module that doesn't require developer work to keep it up-to-date. The Module Is Free This is my first real module and I want to give it back to the community as thanks. This is the best CMS I've worked with (thank you Ryan & contributors) and a great community (thank you dear reader). DeepL Developer Accounts In addition to paid Pro Developer accounts, DeepL now offers no-cost free accounts. Now all ProcessWire developers and users can use Fluency at no cost. Learn more about free and paid accounts by visiting the DeepL website. Sign up for a Developer account, get an API key, and start using Fluency today. Download & Feedback Download the latest version here https://github.com/SkyLundy/Fluency-Translation/archive/main.zip Github repository: https://github.com/SkyLundy/Fluency-Translation File issues and feature requests here (your feedback and testing is greatly appreciated): https://github.com/SkyLundy/Fluency-Translation/issues Thank you! ¡Gracias! Ich danke Ihnen! Merci! Obrigado! Grazie! Dank u wel! Dziękuję! Спасибо! ありがとうございます! 谢谢你!
    1 point
  16. In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.
    1 point
  17. The decimal fieldtype is available and works well (I use it for an ecommerce site with large numbers, no problems): However it would be nice if this was in the core: https://github.com/processwire/processwire-requests/issues/126 FieldTypeTable supports decimals by the way.
    1 point
  18. Two distinct points of view: Majority of the sites I work with require some sort of public API. This may be for local JavaScript, or perhaps I need to expose (as raw data or pre-rendered views) content to an external service. With this in mind I've been working on a built-in API for the Wireframe module and I've also got something similar planned for SearchEngine. In WordPress, plugins can inject their own custom endpoints to the global REST API. That in turn makes it easier to integrate with existing core or third party features (authentication and whatnot), things are more straightforward for plugin authors (no need to reinvent the wheel), and it's also easier for API consumers (familiar interface). Perhaps worth noting that this is not actually limited to front-end: it can also facilitate behind the scenes plugin-to-plugin integrations quite nicely. Let's say that I want to distribute a module that is focused on front-end features. Currently it would need to provide both back and front-end, since there's no public API I can tap into. SearchEngine might be one example of this: if there was a public API, I might be able to use that instead of implementing one of my own. I could list other examples, but the gist is that any front-end feature that needs to talk to the backend might benefit of this. If there was a public API (and by public I mean something accessible to, say, JavaScript) one could essentially develop front-end features, bundle them in a module or distribute in other ways, and then integrate them with ProcessWire without a need for a purpose built custom backend. In a way this would create a whole new market / open ProcessWire up for a new type of audience. Agreed, my experience is similar. New users tend to find ProcessWire very easy to use (certain differences in personal preferences aside), while much of the feedback regarding things like not having a sidebar seems to come from users with experience from other systems. Perhaps you're further down the adoption curve? One can always hope 🙂 A few years ago it was easier to convince clients to try other platforms, today it's common for WP to be not just a strong recommendation but actually a strict requirement. I guess it boils down to the idea that if you're not an expert and have to make a decision about which offer to accept, the popular system is a safe bet. Also if you're requesting quotes and 4/5 recommend platform X, it does make one wonder if the majority could really be wrong. Thanks 🙂
    1 point
  19. I was just about to ask for a release date, too :-) Seems I'm not the only one who is keen on getting their hands on this. As I understand it, this will be released as a paid module which is only fair. @flydev 👊🏻 mentioned that he wants to get the promoting website up and running before selling the module. Just in case that this is slowing things down, I would even be happy to pay for a pre-release version.
    1 point
  20. @Kiwi Chris - sorry, I didn't initially understand what you were looking to do. It sounds to me like the new Combo field is exactly what you are looking for. It dynamically adds/removes actual DB table fields as you modify the combo field's subfields, so it allows you to sort, group, query like you would with any regular SQL DB table. It is not at all like the custom file/image fields which are stored as JSON.
    1 point
  21. Depending on how much mixing of relative and absolute dates occur on a single page, it might be possible to avoid those scenarios by excluding specific processes and/or URL segments, e.g. if($page->process != 'ProcessPageEdit') { $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); }); }
    1 point
  22. A dedicated field for height is definitely the way to go, but just wanted to add that for the example titles you gave, the height follows the noun and if that applied consistently then potentially you could include the noun in the search text:
    1 point
  23. And if you want the height to appear after the title in the page tree, you can use the "List of fields to display in the admin Page List" setting on the Advanced tab of the template's settings. And if you want to go even further and convert cms to decimal meters, you can use a hook something like this: $this->wire()->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $p = $event->arguments[0]; if($p->template == 'tree') { $event->return = $p->title . ' ' . ($p->height_cm / 100) . " m"; } });
    1 point
  24. This is tricky because for the database "1,5m" is neither a word nor a number, so the comma is treated as a word boundary. This is why can't use selectors that make use of fulltext indexes (*=, ~=). The only option in this case is a slower LIKE comparison (%=), but that isn't aware of word boundaries, resulting in your problem with matching "11,5m" as well as "1,5m". A quick and dirty solution would be to include the space in your selector, but I'm not even sure if ProcessWire won't filter out any leading/trailing spaces in selector values: 'title%=" 1,5 m" The best solution is to turn the height of the tree into its own field which can be searched and compared properly. For the height, a simple integer field containing the height in centimeters would be appropriate. Then you can easily search for trees of a certain height, or even within a certain range of heights: // all trees that are exactly 1,5m high $trees = $pages->find('template=tree, height_cm=150'); // all trees that are between 1 and 2 meters high $trees => $pages->find('template=tree, height_cm>100, height_cm<200');
    1 point
  25. Just one thing to consider - it may result in some weirdness when both actual and relative versions are shown together, eg:
    1 point
  26. You can use a hook to replace all relative time strings in admin with a specific date format. Add the following to /site/templates/admin.php, at the top after the namespace declaration: $wire->addHookBefore('WireDateTime::relativeTimeStr', function(HookEvent $event) { $timestamp = $event->arguments(0); // If given a date string, convert it to a timestamp if(!ctype_digit("$timestamp")) $timestamp = strtotime($timestamp); $event->replace = true; // Set your preferred date format below $event->return = date('Y-m-d H:i:s', $timestamp); });
    1 point
  27. Definitely one way to do it. My suggestion was largely based on the experience of working with code review in a previous job: CR is as much about education (nurturing a more productive team of contributors) as it is about making sure that the quality is solid. Obviously these approaches are not mutually exclusive 🙂
    1 point
  28. I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.
    1 point
  29. This is really well explained! I sometimes end up with "Text w/ Image", "Text w/ graph", "Text with quote" block types which works and helps with getting the css styles around these blocks to work as expected, but it would definitely be nicer to have a way to make interspersed content cleaner. Agreed!
    1 point
  30. @Zeka Thanks, I still feel this is redundant in PW, but it's been mentioned enough times that I can't rule it out. So will keep eyes open here. Yes, if you mean things like S3 storage or similar, this is something I've been interested in too. This is definitely on my wishlist too.
    1 point
  31. Regarding @teppo's suggestion about a native external API - I know that we just lost one PW website to a JSON / GraphQL / Gatsby / React stack because the developer decided that was easier to do that than use GraphQL / Gatsby / React on top of PW. Personally I think his decision was misguided because now he is managing content in json files (he is the sole dev / content editor so he doesn't need an admin CMS), but I think he'd have done much better using PW for content management and generating JSON that can be pulled into the frontend. But maybe if PW had a native way of doing this, he might have stuck around and I am sure there are lots of other devs out there that ignore PW simple because they don't think it will let them use these modern frontend stacks. I do think an integrated javascript API would make lots of things much easier as it always feels a bit hacky to me getting PW data into JS - it would be great to have JS page object available on page load, but also to have a built in AJAX method to pull other PW data on demand. I do feel like we need to convince potential developers that PHP can work together with the rest of the tools they want to use - they don't need to use Node to integrate things. I am still baffled that companies are paying thousands of dollars a month for things like Contentful or ContentStack when PW can essentially do the same thing - I know there are other benefits to these services, but I find the downsides not worth the tradeoff. There are of course self-hosted headless CMSes out there, like https://strapi.io/ which has been around since the end of 2015 and has 32,000 Github stars and 600 contributors. I know you have constantly maintained that you don't care about popularity, but clients often do, and with good reason - they need to know that there are other developers out there to take over if needed. The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice. One thing I would like to see is a way to easily implement certain admin forms in the frontend - yes we can do this with the API, but having all the admin tools available in the frontend would have saved me a lot of time over the years essentially rebuilding functionality. Sometimes I can get away with the AdminBar module, but it's not always appropriate. If you want an idea for another profield, a properly working version of a recurring dates field would be awesome. Unfortunately the Recurme module just isn't a viable option - I do have it running in production, but it's not efficient and I have several hacky fixes in place. It's actually a difficult problem doing recurring dates well, but it is a common need for lots of sites and so a good implementation would be very popular. However, my biggest concern and bugbear has always been what some might consider little things, but these "little things" can sometimes cause lots of frustration - things like: https://github.com/processwire/processwire-issues/issues/550 - there are lots of other examples of these sorts of things that require hacky workarounds. It is much more important to me to find proper solutions for these than adding fancy new features. I'd also like to see the admin user interface tightened up - there are lots of areas for improvement and so this is just one silly example, but having the double-click to open/close all repeater items on the on/off toggle button is confusing and I think needs fixing. I have converted a local web dev agency to be exclusively PW (from Drupal), but whenever we chat, their main complaint is always the look of the admin - they feel it doesn't look modern and clean enough and makes PW look a bit cartoonish. Please don't take that as a personal insult - getting this right is difficult and in my mind take a very talented design person to get the details right - I can see the things that are jarring, but I am not good at figuring out how to make them right. I think this is really important in ensuring that PW continues to be something that we can convince clients is a modern platform. I do also think that the interface to RepeaterMatrix could be modernized. I am not a huge fan of fancy website builders, but I do think we need to find a middle ground between what RepeaterMatrix currently provides and the best of the new building tools out there, because eventually clients will complain that they don't have access to the shiny new tools - it hasn't happened to me yet, but I think that's partly because of the type of clients I typically have.
    1 point
  32. Oh. One more. I get that this is literally something you said you're well aware of, but I'd still like to say that I would absolutely love to see more pull requests get pulled into the core this year 🙂 This has been brought up many times over the years, but the truth is that "if ProcessWire is so good then why are only a handful of people interested in contributing" is still one of the FAQ's I ever so often find myself answering. At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. I want to be able to justify why I'm not using the most popular platform out there, and sadly it's getting harder and harder by year (and a rather low number of contributors isn't helping, at the very least).
    1 point
  33. It's because, packagist automaticly creates versions of a package, so you can specify which version you want to install. Without tags you can only install dev-master version (current latest commit) which composer considers as development while tags considers as stable. With tags composer installs the latest tagged version if you don't specify any, but if there is none you have to explicitly specify dev-master if your composer json is not configured to accept it automatically. See my module https://github.com/uiii/ProcessWire-FieldtypePDF as example.
    1 point
  34. Ah, good! Yes, this is also the way. But I see composer as de-facto standard for maintaining dependencies, not only PW modules. I'm used to npm in JS world and love it, so composer is the way for me. Great, thank you. One more thing you could do is to add git tag for each released version, or at least add the latest one.
    1 point
  35. Thank you for quick reply! I will take a look at it. I see composer installation really useful because I've just specified all dependencies in composer.json file and don't have to commit modules into my site's source code. So, when I deploy the site to production the automated script easily install all dependecies. All I have to do manually is to install the modules via admin (maybe this could be automated as well) or refresh if they are already installed. I've even created a "wrapper" composer package for processwire (see https://github.com/uiii/processwire), which will install like a regular installation, or upgrade the existing. So my site's source code only contains the site folder (without modules) and composer.json (and composer.lock) and this is enough basis to setup the whole running site by single command: composer install
    1 point
  36. Not true, actually. You can: See these lines, here and here: $str = sprintf($this->_('%1$s %2$d of %3$d'), $label, $pageNum, $totalPages); // Page quantity, i.e. Page 1 of 3 $str = sprintf($this->_('%1$s %2$d to %3$d of %4$d'), $label, $start, $end, $total); // Pagination item quantity, i.e. Items 1 to 10 of 50 Here's how to do it 🙂 Setup -> Languages -> Your Language Find Files To Translate Look for \core\PaginatedArray.php under Translatable files in /wire/ Select #3 Click Submit Translate!
    1 point
  37. Ok this is awesome then - best of both worlds! One other feature request that will make this a killer module IMO... that it should work with Front End editing.
    1 point
  38. I think I get what you mean @Guy Incognito Actually, you can move every single paragraph independently - BUT, you can also copy/cut all the selected paragraphs and move them as it was a "one-block".
    1 point
×
×
  • Create New...