Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/28/2018 in all areas

  1. What @LostKobrakai said. The short answer to "what can Laravel and Symfony do that PW cannot" is "nothing", but in my opinion that's not really the question you should be asking – rather you should ask what it is that they are better suited for than ProcessWire ? In my experience (based on other web application frameworks, not Laravel or Symfony specifically) the biggest day-to-day difference is exactly the general purpose nature of web application frameworks: ProcessWire is specialised to content management, hence it's a "content management framework" (CMF) rather than a "web application framework" (WAF). In some regards ProcessWire has more built-in stuff than WAF's, and in some regards it has less – just like LostKobrakai pointed out above ? Some examples of the differences include routing and project structure / application architecture: Although this might be changing, not too long ago it seemed that every PHP framework enforced MVC pattern, or at least recommended it. ProcessWire, on the other hand, doesn't (natively) include anything like that. The default, out-of-the-box approach ("output strategy") is a straightforward solution where single template file contains (or rather can contain – of course you can also split it into multiple include files) all the code required by said template. Similarly in ProcessWire URLs are by default routed to pages, and although custom routing is technically possible using URL segments, there's no real, robust routing library included, other than what Pages / PagesFiles / Process modules require to function properly. While it's true that you can build pretty much anything on top of ProcessWire (or WordPress, or Drupal, or any remotely flexible CMS/CMF for that matter), whether that's a good idea depends on a number of factors. For an example, if there's no content to manage – or the content you have requires a very specific type of structure or storage mechanism or something – a general purpose WAF may provide you with more suitable tools than most CMS/CMF platforms ? Just for the record, https://madewithlaravel.com/ has quite a few examples of stuff built with Laravel. Some could've made at least as much sense as ProcessWire projects, while others are clearly better suited for a WAF.
    6 points
  2. Laravel or Symfony are first and foremost general purpose frameworks, while ProcessWire is first and foremost a CMS with the benefit of having a small general purpose framework beneath. The difference lies mostly in what you get out of the box and less so in what you can build with it. E.g. laravel/symfony have components for using queues, processwire doesn't, laravel/symfony have a templating system, ProcessWire doesn't (it's php), …. On the other hand ProcessWire comes with a flexible backend to hook into, laravel/symfony don't have that (laravel nova would be similar, but costs money).
    5 points
  3. Howdy PW Gurus Who Also Know Laravel or Symfony, I built a few web applications with PW, and was very happy with the result. For example: - an email to web help ticket system, with a front-end login - a Linux account management and multi-server account creation app, with a front-end login and PW server scripts run from the command line - a complex business app to test the viability of business ideas against a variety of metrics and algorithms, with a front-end login. The front-end logins displayed pages specific to the app needs, entirely bypassing the normal PW admin backend. => My question is: since PW can build the types of apps above, what can Laravel and Symfony do that PW cannot? Thanks for any insights! Peter
    3 points
  4. I strongly support @LostKobrakai 's approach. JSON looks nice at first sight, but we already have a powerful API and we MUST use it. JSON is basically only another syntax. It's some kind of an "API" but a lot less powerful. It's also not easier IMHO, because using the API we have intellisense in our IDE. You don't get that when using JSON. Updates are a pain using JSON. It might be easy to setup new fields and templates, but what if you want to set a new field width in template context? How would that look like in JSON? It's as easy as that with migrations: $this->editInTemplateContext('basic-page', 'headline', function(Field $f) { $f->columnWidth = '50'; }); The example is also in the screencast. Another one: How would you create pages in JSON? We know the problem because we already have this tool built into PW. You'll always end up with collision warnings needing some more user input (add this field after that, do you want to overwrite or rename etc etc). You can handle all that with migrations. It is also quite easy to find the correct property names now as we have Tracy (see end of screencast). And it's also easy with intellisense in your IDE. Where I see potential for the future is that migrations could be used in other modules as well. I think it would make sense to move the migrations feature into the core to have a solid base that is consistant, bullet-proof and maintained together with PW. I think it would make sense to have migrations inside modules, not only at one place. We could then build modules, ship some migrations with it (eg for creating pages and fields) and run / revert those migrations from within the module. I think that solution would be way better than the JSON config approach and I'd love to see this as a huge update to PW in 2019 @ryan ? PS: Also take a look at the great docs and examples here: https://lostkobrakai.github.io/Migrations/examples/
    3 points
  5. Security Report: FYI TL;DR: Our module does not use the vulnerable PHP files. We are OK; nothing to see here ?. You might have come across reports that Blueimp jQuery File Upload on which the module JqueryFileUpload is based had some vulnerabilities that had gone undetected for 8 years! The vulnerabilities, that have since been fixed, had to do with the server-side application examples that ship with Blueimp jQuery File Upload, specifically the two PHP files Upload.php and UploadHandler.php. Our ProcessWire JqueryFileUpload module is not in any way affected by the vulnerability. Here's why: We don't use Upload.php and UploadHandler.php nor any server-side samples that might ship with Blueimp jQuery File Upload. We use ProcessWire's WireUpload Class instead. We don't ship our module with these files. We use Blueimp jQuery File Upload purely for its client-side upload capabilities (only the JavaScript). Blueimp jQuery File Upload aside, we operate a very tight ship with our module. These include: Not everyone can upload files. That decision is left to the developer. All files are validated for both MIME types and file extensions. Only extensions specified by admin are allowed to go through to validation. All uploads are stored in a temporary folder pending validation. The location of the temporary folder is configurable. One can set either a web-accessible folder (e.g. in cases where one wants to show thumbnails of uploaded images) or a hidden one. All actions sent from client-side are validated against settings stored server-side. For instance, uploading, listing and deleting files. So, changing a JSON setting sent to the module client-side has no effect server-side. We use CSRF. Etc... Here are the relevant links to the above mentioned (but now fixed) exploits. https://blogs.akamai.com/sitr/2018/10/having-the-security-rug-pulled-out-from-under-you.html https://www.exploit-db.com/exploits/45584 https://github.com/blueimp/jQuery-File-Upload/blob/master/VULNERABILITIES.md https://github.com/blueimp/jQuery-File-Upload/blob/master/SECURITY.md In conclusion, this is just for your information, in case you were wondering or came across it. We are not affected and we didn't have to patch anything. Having said that, as per our OP, we urge all developers who use this module to exercise best practices to secure their applications.
    3 points
  6. The problem I have with static json or yaml setup files is that it's not migration. It's just a static set of fields/templates/… without knowledge of what came before or after. I have almost always user generated data associated to a certain setup. So when changing the setup there's often the need for something to happen with said data as well, like when adding a new intro field for blog posts one might want to put the first paragraph of existing posts from the body into the intro. Craft seems to see their addition just as replacement of sharing db dumps and it's essentially that. If environments never concurrently change in terms of content, but just structure then some version controlled file for the structure is better than a db dump, which contains both structure and content. But as soon as the content is also affected by changes it's no longer a solution.
    3 points
  7. Does this help: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#page-gt-references
    3 points
  8. emplate Field Widths Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template. Since v0.2.0 the module also adds a similar field to the settings of Edit Field for Repeater, FieldsetPage and Repeater Matrix allowing you to quickly set the widths of inputfields within the Repeater/FieldsetPage field, or within each Repeater Matrix type. Note: widths are only saved if the edit form is submitted with the "Field widths" field in an open (non-collapsed) state. Edit template Edit Field: Repeater Edit Field: Repeater Matrix Why? When setting up a new template/repeater or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process. Config options You can set the default presentation of the "Field widths" field to collapsed or open. Widths entered into the "Field widths" field are only applied if the edit form is submitted with the field in an open (non-collapsed) state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width. https://github.com/Toutouwai/TemplateFieldWidths https://modules.processwire.com/modules/template-field-widths/
    2 points
  9. Since I posted a feature request for something similar without knowing this discussion was happening, just thought I'd chime in. Obvjously json sync has drawbacks, but here is the workflow I have experienced using ACF with Wordpress that works really well: LOCAL (clone of REMOTE) | REMOTE (source of truth) LOCAL - work on fields and perhaps content / other config such as templates LOCAL - check auto generated field json into version control for other devs to pull, or push to REMOTE as part of deployment REMOTE - sync field updates in admin, and if other config / content mismatches then things fail gracefully To explain the last step, say you have added the field to a template on LOCAL that doesn't exist yet on REMOTE, then on REMOTE nothing goes wrong and if you re-save the field on REMOTE it just updates to the current state there. This is about syncing fields, not other config, so things should just fall back to default if relying on other config that could conflict. I can definitely see how content (not other config) can quickly become a problem when moving outside of this workflow, but if all you are doing is testing things locally, pushing to live, then syncing the database from live back down to local, this is a really quick and efficient way of iterating field updates and sharing with other devs.
    2 points
  10. I've managed to resolve the problem. I actually still think the issue might be a core ProcessWire one, but at least I know how to fix it now. Yes, I'm using the PW3 branch of Padloper, and it's working fine on other sites on my WAMP setup. I'm using AIOM+ on many sites with PW3 and it's working fine on all the others. I tried manually deleting all the entries in the cache table in phpMySQL and that allowed me to get into the site admin again temporarily, although it gave some notification about some modules that actually are present not being installed. I went to modules, and did a refresh, and the error came back. One thing I noticed that I wonder about, but don't know enough about how Processwire handles loading modules, is looking at the Modules.site/modules/ entry in the cache table, the modules seem to be listed in alphabetical order, and the offending module that is generating the error is listed before the module that it depends on, which it claims can't be found. I'd hope this shouldn't matter, as it could have serious implications for module naming, as the offending module was working previously, but it seems it does. I manually edited the order of the modules listed in the cache entry via phpMySQL, and the error went away. I've tracked down the issue with AIOM+ I think. There was a namespace conflct in that a reference to a root PHP class was picking up the ProcessWire namespace and obviously not working. I think I must have added a namespace statement to the module so that the module compiler didn't have to do it, but forgot to check any possible conflicts. The good news is AIOM+ works fine without namespaces in Processwire 3.x I think the AIOM+ problem might have actually been a red-herring with me trying to add namespaces to everything to try to get the first error to go away. The real culprit here is that if the Modules.site/modules/ gets regenerated somehow, it seems it can potentially break a site, as it will add modules in alphanumeric order, and if a module depends on another one that comes later in the sort order, then the class will not be found. This can be fixed with careful naming of modules so that a module that has dependencies will always be listed after any dependencies, so in the case of PaymentInvoice, since it depends on PaymentModule, it probably should have been called PaymentModuleInvoice which would ensure that regenerating the modules cache would always load it after PaymentModule.
    2 points
  11. Since some others and me have been run into problems with FieldtypeFloat. I want to start a discussion with the purpose to get a consistent FieldtypeFloat and/or to create a new Fieldtype maybe called FieldtypeDecimal to store exact values maybe for currencies. First I will assume some known problems. precision Values of Type Float are stored in most of the Mysql Installations with a precision of 6 by default. PW FieldtypeFloat uses Type float() in the Mysql Database This could cause some problems. For easy understanding look at this table. +---------------+----------------+--------------------------------------------------+ | input | float() | decimal(10,2) | +---------------+----------------+--------------------------------------------------+ | 1234.56 | 1234.56 | 1234.56 | +---------------+----------------+--------------------------------------------------+ | 123456.78 | 123457 | 123456.78 | +---------------+----------------+--------------------------------------------------+ | 12345678 | 12345600 | 12345678.00 | +---------------+----------------+--------------------------------------------------+ | 1.23456789 | 1.23457 | 1.23 | +---------------+----------------+--------------------------------------------------+ | 12345678912345| 12345600000000 | ERROR SQLSTATE[22003]: Numeric value out of range| +---------------+----------------+--------------------------------------------------+ As an example in Apeisas Shoppingcart Module exists a field sc_price of type float(). This field allows a maximum value of 9999.99 Euro Dollar or whatever. Don't use it to sell cars like Ferrari. Try to store the input values of the preceding table in a PW Field of Type Float in your surrounding and look what you get after saving. Threads treating the same problem https://processwire.com/talk/topic/3888-float-field-rounding-problem/ https://processwire.com/talk/topic/86-float-field-rounding rounding Mysql will round anyway the float value to precision. So it is not necessary to round the value in php before storing. To store exact Values it is better to use Type decimal(M,D) where M is the lenght and D the number of digits. Thread treating the same problem https://processwire.com/talk/topic/86-float-field-rounding format We had already some discussion about local settings, storing and output of PHP-Values of Type (float). And Ryan did some Adjustments with number_format. But I don't trust completely, thats why I am using Textfields to store numbers. Would be nice to have a consistent Fieldtype working in different local-settings. Thread treating the same problem https://processwire.com/talk/topic/4123-decimal-point-changed-to-in-base-of-setlocale/ https://processwire.com/talk/topic/86-float-field-rounding What is a float (floating point value), what is decimal? A float is an approximate value and exactly like this it is stored in Mysql. For more understanding two examples. 1. example CREATE TABLE `test` ( `test_float` float(10,2) NOT NULL, `test_decimal` decimal(10,2) NOT NULL ); INSERT INTO `test` (`test_float`, `test_decimal`) VALUES (5.43, 5.43); SELECT (test_float * 1.0000000) AS f, (test_decimal * 1.0000000) AS d FROM test; This will result the following: f = 5.4299998 and d = 5.430000000 source: http://netzgewe.be/2012/03/mysql-und-waehrungsbetraege-float-vs-decimal/ (german) 2. example mysql> create table numbers (a decimal(10,2), b float); mysql> insert into numbers values (100, 100); mysql> select @a := (a/3), @b := (b/3), @a * 3, @b * 3 from numbers \G *************************** 1. row *************************** @a := (a/3): 33.333333333 @b := (b/3): 33.333333333333 @a + @a + @a: 99.999999999000000000000000000000 @b + @b + @b: 100 source: http://stackoverflow.com/questions/5150274/difference-between-float-and-decimal-data-type INFO & LEARNING http://stackoverflow.com/questions/5150274/difference-between-float-and-decimal-data-type http://stackoverflow.com/questions/4520620/float-precision-problem-in-mysql http://dev.mysql.com/doc/refman/5.0/en/problems-with-float.html http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html INTENTION The intention of this thread is to discuss good solutions for a consistent working FieldtypeFloat which makes clear to Everybody what it is via description. Furthermore to build a new Fieldtype with setting options of total lenght and decimal places. NOTES Please use this thread rather for development than as a help forum. BTW I am not an expert in Mysql PHP or whatever. Maybe there are some guys in the forum which could put the real good stuff here. Thanks a lot and lets go.
    1 point
  12. https://www.spiria.com After several sites made with ProcessWire, Spiria decided it was time to get rid of its cumbersome Drupal site. To be honest, ProcessWire is still difficult to sell to customers, because this CMS/CMF is not as well known as the most popular ones. The migration to ProcessWire therefore served several purposes: Eliminate the frustrations experienced with Drupal (especially with image management and some structural problems). Allow integrators to learn the CMS during quiet periods, when they are not needed on other projects. Promote the CMS by adopting it. The challenges were many, but by no means insolvent, thanks to the great versatility of this programming framework. Indeed, if ProcessWire can be considered as a CMS in its own right, it also offers all the advantages of a CMF (Content Management Framework). Unlike other solutions, the programmer is not forced to follow the proposed model and can integrate his ways of doing things. The blog The site includes a very active blog where visuals abound. It was essential to cache the various dynamic components. For example, in all sections of the blog, there is a list of recent articles, a list of "short technical news", another list from the same author, a classification by category. In short, these lists evolve independently. ProcessWire's cache system, including its ability to classify by namespace, has significantly improved loading speed. Cache file management has been placed in a "saved" hook in the useful "ready.php" file. Data migration Importing the blog data was complex because at the time the site was designed in Drupal, programmers had not been used the easily translatable "entities", so each article resided in two different "nodes" (pages). We would have liked to use the core ProcessWire import module, but it does not yet take into account multilingual fields. However, we have used this code as a basis for building our own import module. This is one of ProcessWire's great qualities, as a CMF, it is easy to use existing code to design your own solutions. Reproduce the layout The current layout of the site has been reproduced exactly as it serves the company's needs very well. ProcessWire has simplified the work in many ways. Apart from the blog, which is very structured, the other sections of the site are more free, especially the case study section ("Our Work"). The use of page reference fields has particularly helped developers. As everything is a page in ProcessWire, you can create a pseudo relational database within the site itself. The administrator user becomes more aware of the data hierarchy and has better control over the data. Programming architecture The separation between controllers and Twig visualization files facilitates the management of the multiple components of the site. We haven't really explored the "regions" of ProcessWire, because we prefer not to mix these aspects of programming. This greatly facilitates the timely arrival of programmers in our department, used to an MVC structure, because they have a better understanding of what does what. The Search Once again, we were able to simplify what had been done in Drupal. There are two types of searches on the site, the blog search and the more general search on page 404 ( https://www.spiria.com/potato). The Drupal site search was driven by an Apache Solr server in Drupal. We decided to rely on the ease of ProcessWire and the Typeahead library (for the blog), because we didn't need the power of Solr (or Elasticsearch) anyway. Work to improve performance still needs to be done in this area. We would have liked to have seen the excellent search tool offered on the administrative side available on the frontend. We have not yet had time to explore the possibility of harnessing this code from the core of ProcessWire. Our wish here is that the CMS designer, Ryan Cramer, sees this as an opportunity to offer an exciting new feature to his CMS! Powerful modules We have the excellent modules ProCache (static caching), ProFields (fields that greatly improve the functionality of existing fields) and ListerPro (data search and processing tool). As the site is installed on a nginx server, we have ruled out ProCache for the moment and we are satisfied with the use of the cache() function alone. The ProFields fields are a blessing just like ListerPro. This last module is very useful to correct, for example, import errors (we had more than 800 blog articles, some of which date back to 2013). We used a functional field to gather translations of terms that would normally have remained hard coded and difficult to access in the translation interface (an aspect to be improved in ProcessWire, in our opinion). By grouping translations in a single page, site administrators can easily change or correct terms. Language management What remains a very small irritant for us is the management of languages, which is fantastic in many ways. The fact that there is a default language is both a blessing and a problem. For example, in 2013, blog articles were not systematically translated. We experienced the same situation with a customer's site. If the article is only in English, no problem, we only have to not check French as an active language. However, if the article is only in French, we are still required to create the page in English and make tricks in the code, thanks in particular to a checkbox such as "Not present in English" to reproduce the behaviour naturally present for English (or any language deemed by default). Perhaps there is a more elegant solution here that we have not yet discovered. It's not much, but some clients don't see why there are two ways to do it here. In conclusion In any case, ProcessWire's great qualities continue to appeal to programmers, integrators, graphic designers, users and even our UI/UX expert. The solidity of the CMS/CMF, its functionalities all translated into objects/variables ($pages, $page, $config, $sanitizer, $input... the list is long) allows us to systematize our workflow, easily recover code and reduce production costs. Although it is dangerous to offer only a CMS solution to our customers (hammer syndrome that only sees nails), it is tempting to consider ProcessWire as the Swiss Army knife par excellence of Web programming. As mentioned above, the CMF is suitable for all situations, has very good security tools and its designer has successfully improved PHP methods to make programming very pleasant and intuitive. For us, migrating the company's website to this platform was the best tribute we could pay to its designer, @ryan.
    1 point
  13. This part doesn't look quite right for a couple of reasons... Firstly, the value of a repeater field is a PageArray even if the field is empty, so is_null() is never going to return true regardless of whether there are any repeater items. Secondly, if film_days is a repeater then you have to loop over its value - you can't get a field value of a child repeater item with $p->film_days->film_times So for that section of code I think you want something like: // remove all the old data (verbose) if($p->film_days->count()) { foreach($p->film_days as $film_day) { if($film_day->film_times->count()) { $film_day->of(false); $film_day->film_times->removeAll(); $film_day->save(); } } $p->film_days->removeAll(); $p->save(); } ...and to shorten it I don't think you need to worry about removing film times in film days you are about to also remove - just remove the film days and the film times will be gone too: // remove all the old data if($p->film_days->count()) { $p->film_days->removeAll(); $p->save(); }
    1 point
  14. This new plugin module is a great helper for setting up fields widths for layout:
    1 point
  15. Am I right in assuming that a call to $pages->uncacheAll() between the two parts makes it work?
    1 point
  16. completly OT, but are you sure that this concept, a repeater in a repaeter in a repeater, is a good way to go? At least the (starting ?) times could be handled by page references, I think. Not knowing anything of your data, but A day can have max 24 hours and each a max of 60 minutes, results in 2 pagereference fields or two option fields. And maybe if you can work with a more limited amount of (starting ?) times, you only need one field with a list of fix / predefined times. And to your question: Debug your code by inspecting why your page 0 has no parent page, starting by inspecting what template it is assigned to. This way you will find where your logic is not practicable and need to be changed.
    1 point
  17. Thank you @kongondo for this information. That shows the exemplary security awareness of @ryan in all his work! One of the reasons that makes us glad using PW...
    1 point
  18. Hello Adrian, Sure does! ended up going with $page->numReferences; after updating to the latest version of PW Thanks
    1 point
  19. I don't know If I can do it but I will try.
    1 point
  20. I guess it should be doable by extending WireDT accordingly and implementing fitting getDatabaseSchema and savePageField/loadPageField methods as well as making sleepValue/wakeupValue with arrayish data instead of plain strings, a lot like the Events fieldtype but without the multiple value (EventsArray) stuff. Meanwhile reproduced and working on a solution. Should be ready in a few days at most. Meanwhile, I haven't been completely lazy: DatetimeAdvanced v1.0.3 supports custom subfields and works together with Lister's subfield selectors.
    1 point
  21. I wonder if adding this to your site's /site/config.php file will work? // I receive a warning when visiting the admin area // Warning: your server locale is undefined and may cause issues. Please add this // to /site/config.php file (adjust “en_US.UTF-8” as needed): setlocale(LC_ALL,'en_US.UTF-8'); setlocale(LC_ALL,'en_US.UTF-8');
    1 point
  22. I asked my hosting company to install the timezone tables and they said it's not possible on shared server and changing manually the offset is bad but then I found about the capital "I" on date format where we can easily detect if the DST changes. So here is the best solution: if (date('I', time())) { $config->dbInitCommand = "SET NAMES '{charset}', time_zone = '+03:00' "; } else { $config->dbInitCommand = "SET NAMES '{charset}', time_zone = '+02:00' "; }
    1 point
  23. First of all, thank you for your module. I'm using the PW FormBuilder module embedding forms in <iframe> HTML tags. When a user accesses for the first time the page that has an "iframed" form then the user sees two EU-Cookie-Law messages, one under the page (BTW I set the EU-Cookie-Law message position to bottom) and one under the form (BTW This causes the message to override the submit button). I'd like to do not show the EU-Cookie-Law message under the "iframed" form but only under the page. How can I make that (e.g. by using selectors for the "iframed" form-page)? Update Perhaps I found a solution: I think the first solution is better than the second one... but how will this affect the performance of the web site (if it will do)?
    1 point
  24. The problem is that a middleground is even more complex. Either your prod environment doesn't change (in terms of what's in the db) then you can simply use db dumps, or your production environement's db does change concurrently to the dev db. The same is the case if you're working in a team of people as well. If the latter does happen you need some way to know what to update and what not to touch. Migrations is doing that by letting you manually define migrations, which are the stuff, which needs to be changed. This gives you full control and you can basically update anything in processwire by using the api. You can also still do stuff on your dev environment, which is not somehow automatically applied as change to prod. Bonus point: replayablility / reusability. What you're looking for is some way to basically let the computer do what you've to do manually with my module: detect what's to change. This could work for simple changes like in fields or templates, but does easily get quite complex is the not so simple cases, e.g. repeater matrix. For pages it's already getting not that simple. You might create pages, which are just for your dev work or pages, which need to be created in prod as well. One could manage whitelists or blacklists (of branches), but that's also a thing to maintain. Also if such a module is not super flexible you'll be bound to execute what it thinks did change. Most often such algorythms don't like a human to adjust their results, especially if steps depend on each other.
    1 point
  25. @matjazp, thanks for the suggestions. Yes, done in v0.1.2 Sorry, no, if I'm wanting numbers to sum to exactly 100 then I much prefer a number input than a slider. Just tab from field to field and it's very quick. Great idea, done in v0.1.2
    1 point
  26. While it is not an 'out of the box' solution, it is perfectly possible to for instance to use the RestAPI module to parse any bit of content, such as (items from a) repeater matrix. Just like when you would write your regular template logic, it does require some custom programming on your end though: you will have to go through the matrix' items and decide how they should be presented through your API. Which is exactly the flexibility which makes PW our go-to solution for pretty much any modern (headless) webapp or old-school site! ?
    1 point
  27. Hey, @jrtderonde! If you have some money to spend, maybe you could approach @dadish and hire him to modify his GraphQL for ProcessWire module to handle Repeaters and Repeater Matrix fields? If you decide to make it open source, this would be an amazing contribution to the community. I also tend to use the RepeaterMatrix as a flexible content builder ?. Suggesting this because you talking about agency and long term plans.
    1 point
  28. @eelkenet Thanks for using this module and I'm glad it is useful to you ? This is actually the first time, I've heard about the @Operator regarding errors. However, I found an interesting paragraph on the page you have linked to in your post: So I added a line, which checks for the error reporting before displaying an error: https://github.com/thomasaull/RestApi/commit/fe63cc48cfcc6d58489f019d5026764cb60d14e5 Could you please manually download the module from the develop branch on Github and give me quick feedback if this resolves your issue? https://github.com/thomasaull/RestApi/archive/develop.zip
    1 point
  29. You don't need an extension, just add vscode://file/%file:%line to tracy. https://code.visualstudio.com/docs/editor/command-line#_opening-vs-code-with-urls
    1 point
  30. I submitted a request to include it in the core: https://github.com/processwire/processwire-requests/issues/126
    1 point
  31. hi @kongondo did you think about my suggested new render method? another thing that would be good imho is to mention in the docs / in the first posting that you can do this return ProcessWire\wireRenderFile('fields/myfieldsphpfile.php', ['page' => $page]); To have the currently edited page available in your file. It's very basic, but might help some beginners. I would also suggest to update my render-method passing the $page and $pages variables to the renderfile: // change this $str = wireRenderFile($root.$file); // to that $str = wireRenderFile($root.$file, [ 'page' => $page, 'pages' => $pages, ]); what do you think?
    1 point
  32. <?php /** * getFieldsetOf * * for ProcessWire * * gets fields inside a fieldset of pages or templates * choose to retrieve values * * @param Template|Page $context the page or template * @param String $fieldsetName name of the fieldset * @param bool|boolean $collectValues want to collect values of the pages fieldset? * @param string $fieldsetCloseIdentifier default: '_END' * @return FieldsArray|WireData returns FieldsArray or if data wanted, WireData */ function getFieldsetOf($context, String $fieldsetName, $collectValues = false, $fieldsetCloseIdentifier = '_END') { if ($collectValues === true && $context instanceof Page) { $collectedItems = new WireData(); } else if($context instanceof Template) { $collectValues = false; $collectedItems = new FieldsArray(); } else { throw new WireException("getPageFieldset: first argument must be of type Page or Template", 1); } if (!$context->fieldgroup->get($fieldsetName . $fieldsetCloseIdentifier)) return NULL; $collecting = false; foreach ($context->fieldgroup as $field) { if ($field->name == $fieldsetName) { $collecting = true; continue; } if ($field->name == $fieldsetName . $fieldsetCloseIdentifier) { break; } if ($collecting) { if ($collectValues) { $collectedItems->set($field->name, $context->get($field->name)); } else { $collectedItems->add($field); } } } return $collectedItems; } Some extension of the above code - works with templates and pages. If thrown at pages you may choose to retrieve the values inside the fieldset as a WireData object. edit: @dragan (below) thanks for the hint! Just removed it.
    1 point
  33. $page->render("some_field") is an alias for $page->renderField(), and passing in an array of your own variables is not supported currently. I agree that it would be useful and have opened a feature request on GitHub.
    1 point
×
×
  • Create New...