Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/19/2019 in all areas

  1. New version release! 1.0.2 I am very happy to inform you guys that the new major version of the module is out. ⚠️ WARNING: Breaking Changes! ⚠️ The module was rewritten to use webonyx/graphql-php instead of youshido/graphql. This was a big issue because the latter was not properly maintained anymore and the webonyx/graphql-php gone very further in development and supports more features that we need. There are some more breaking changes that are listed on the latest release page. What's new trash(id: ID!): Page! field allows to move pages to trash via GraphQL api. Solves N+1 problem for FieldtypePage field. Significantly improves response speed! Support for even more ProcessWire permissions. Now the full list is: page-add page-create page-delete page-edit page-move page-view page-edit-created page-edit-trash-created It is already available in ProcessWire's modules directory. So you can install it via class name.
    11 points
  2. I just found this developer oriented browser which has me excited: https://sizzy.co/ I'm about to play around with it but wow, it looks like it could increase my productivity quite a bit!
    5 points
  3. This is great news! I love using the module, makes integrating Vue with processwire powerful. The only difficulty I had was with the N+1 with FieldtypePage, thrilled this is solved ? Thank you for all your work @dadish
    4 points
  4. Damn, too much work coming on ? Thanks for the new version @dadish ?
    2 points
  5. This looks like a reasonable approach! There is currently nothing like those tools you mention. What I've seen works for a lot of ProcessWire developers is to use the Repeater Matrix module to create content. Take a look here: https://processwire.com/store/pro-fields/repeater-matrix/
    1 point
  6. Just use the root user with no password (of course only for development). See
    1 point
  7. @dadish Great news indeed! Big thanks for this rewrite. Can't wait to try it out (probably not before the weekend).
    1 point
  8. Not a problem at all @kongondo, I know how it goes ? I used the first option with Jumplinks and it WORKS!! Hallelujah, thank you so much for your time.
    1 point
  9. @charger I don't think that hashing graphql queries would cause performance problems. They are not that big. You should be fine.
    1 point
  10. Hey, @alanxptm! I am just guessing, but maybe you got your description filled only in one language, but output the value of some other (probably default) language. And it is blank.
    1 point
  11. ok, i thik found the solution just in case anybody else has this problem, the first time i made the backup recovery using the install.php file from the duplicator backup, at the time i didnt know about the commands to change the user credentials i described in the original post, so the only way i was able to get permissions was using a ssh tunnel and accesed to the file using localhost:8888/install.php, this way every file was attributed to bitnami, but then when frontend users tried to save images their user daemon was not allowed to edit files or folders made by bitnami So the solution is to use the ssh commands to change the permissions and authors BEFORE using the installer.php, this might also be true when trying to use the root installer of processwire, i dont know but if anyone else runs into this problem this might help, thanks to everyone who didn't replied, please leave me a middle finger if you read this
    1 point
  12. Version 1.2.6 as new master version available All information about the changelog and bug fixings in the first post.
    1 point
  13. @JeevanisM I don't think that your issue is relative to module. You can try to use https://processwire.com/blog/posts/introducing-tracy-debugger/#mail-interceptor-panel to see how fast PW sends mail.
    1 point
  14. Hi @Peejay, did you run the Additional steps / Install Snipcart products package in SnipWire module settings? This step installs product templates, files, fields and some demo pages required to build a Snipcart product catalogue. This additional step is needed to prevent unintended deletion of your Snipcart products catalogue when main module is uninstalled. In the current alpha version this isn't yet checked by SnipWire. If you did already run the additional step with an earlier SnipWire version there will be fields missing which were added in a later version. So you will need to re-run this step. The missing resources(fields, templates, pages, ...) will then be installed. Existing ones won't be touched! To re-run this step, you will need to edit/remove a key in database directly: DB table: "modules" -> find entry with class "SnipWire" -> edit the "data" field and remove the Json key: "product_package":true (be sure to leave a valid Json string - you will need to also remove the corresponding comma : {"api_key":"YOUR_LIVE_API_KEY","api_key_test":"ODQzZTc1MjktZGQxNy00YmUzLWFkMWYtZDE3MDQ2YTk1ODNjNjM2ODE3NTg5NzUyNDQxOTc0","api_key_secret":"YOUR_LIVE_API_KEY_SECRET","api_key_secret_test":"","snipcart_environment":"0","single_page_shop":"","single_page_shop_page":1,"credit_cards":["visa","mastercard","amex"],"currencies":["eur","usd"],"show_cart_automatically":1,"shipping_same_as_billing":1,"show_continue_shopping":1,"split_firstname_and_lastname":1,"snipcart_debug":1,"snipcart_css_path":"https:\/\/cdn.snipcart.com\/themes\/2.0\/base\/snipcart.min.css","snipcart_css_integrity":"","snipcart_js_path":"https:\/\/cdn.snipcart.com\/scripts\/2.0\/snipcart.js","snipcart_js_integrity":"","include_jquery":"","jquery_js_path":"https:\/\/code.jquery.com\/jquery-3.3.1.min.js","jquery_js_integrity":"sha256-FgpCb\/KJQlLNfOu91ta32o\/NMZxltwRo8QtmkMRdAu8=","excluded_templates":["promailer-email","promailer-subscribe"],"cart_image_width":65,"cart_image_height":65,"cart_image_quality":70,"cart_image_hidpi":1,"cart_image_hidpiQuality":50,"cart_image_cropping":1,"data_item_name_field":"title","uninstall":"","submit_save_module":"Submit","taxes_included":1,"webhooks_endpoint":"\/webhooks\/snipcart","include_snipcart_css":1,"taxes":"[{\"name\":\"20% VAT\",\"numberForInvoice\":\"\",\"rate\":\"0.20\",\"appliesOnShipping\":[]},{\"name\":\"10% VAT\",\"numberForInvoice\":\"\",\"rate\":\"0.10\",\"appliesOnShipping\":[]},{\"name\":\"10% VAT (Shipping)\",\"numberForInvoice\":\"\",\"rate\":\"0.10\",\"appliesOnShipping\":[\"1\"]}]","snipwire_debug":1,"data_item_categories_field":"snipcart_item_categories","product_package":true} After the key is removed, visit the SnipCart module settings again and re-run the product package installer! In the release version of SnipCart, this will be handled automatically. On each update it will check if there are new fields or other resources to be installed. Hope this helps! p.s. You could also completely uninstall the SnipCart module and then reinstall - this should also activate the product package installer link! -- Martin
    1 point
  15. UPDATE 2019-11-15 In the last 3 weeks I (nearly) finished the complete order handling for store merchants (ProcessWire backend). This includes the following features: search for orders filter orders extensive overview of all order details download of invoices resend invoices to customers refund amounts to customers ... all right from within your ProcessWire backend! That doesn't sound like much, but it was a good piece of work. ? Here is a short clip to demonstrate the new features:
    1 point
  16. The link you're referring to talks about the caching on the client side, not server. And we already have unique id for all the objects. They are page ids and are enabled by default. But that wont help you with caching on the server side. I think using a hash of your queries as a cache name is perfectly reasonable solution. Why do you feel uncomfortable with it?
    1 point
  17. Hi everyone, I can't get my head around this, so maybe someone can help: I want to know how install the dev branch of processwire with composer. I use laragon and the "quick create" function and there you can run composer like this: "composer create-project processwire/processwire %s". OK, this is working, so I will get the master branch from it, but how about dev? I found some examples for laravel on this question, but no luck with it. Here some examples: composer create-project processwire/processwire %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev %s composer create-project processwire/processwire:dev %s --stability=dev composer create-project processwire/processwire:dev %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev-master %s --prefer-dist --stability=dev composer create-project processwire/processwire:dev-branch %s --prefer-dist --stability=dev composer create-project processwire/processwire:@dev %s --prefer-dist --stability=dev and so on... Maybe someone got this already and would like to share?
    1 point
  18. Yes it does. The more fields and templates are enabled the bigger the schema, the bigger the response time.
    1 point
  19. GraphQL requests are slow for sure, but 6 seconds is a bit too much. In my cases it usually took around 200-300ms. Not sure what's causing it to be so slow on your end.
    1 point
  20. AFAIK the only way to ask PW to get you conferences that has particular speakers in it, is to pass which speakers exactly you want. The selector looks like "template=conferences, speaker=1234|1235|1236..." So, you need get the speakers before you can query the conferences. My only solution is to query all your speakers first. Then make another query of all conferences that has those speakers in it. Query them all at once. And then, in the client when you are listing conferences for each speaker, just filter through them. I know, it's not a great solution, but I can't think of another way. I haven't used ProccessWire in a while, so there might be some better way.
    1 point
  21. Please test your query in a Graphiql. Insert your query in the Graphiql and confirm that the "product_single.list" is an array of nulls. Now remove every field inside the list and leave "id" and confirm that the list now contains objects with single "id" property in it. If that was successful then keep adding your "product_single" fields one by one. Whenever you see that the list is an array of "null"s, it means that exact field is causing this issue.
    1 point
  22. I was able to reproduce the similar response from your api. Seems like your guest user might not have access to one of the fields of the "product_single" page. You'll have to go to each of the "product_single" page fields that you are querying and make sure Access is enabled and the guest user has a view access to it.
    1 point
  23. So it is obviously a permission problem. Can you show me the query you're making to your api please.
    1 point
  24. @patricktsg As far as I understand, it's not the httpUrl you are having the problem with. It's the "item" in "item.httpUrl". The error "null is not an object" in JS means you're trying to access a property of a null, in this case "item". So whatever the "item" is in your query, you're getting "null" for it from your api. Then in your JS you're trying to access "httpUrl" of the "null" when you do "item.httpUrl". Hence the "null is not an object" error. So make sure your "item" is not null when returned from the api. If the "item" is a page, make sure the user (in this case guest) has access privileges for that page.
    1 point
  25. Unfortunately I haven't had much time in optimization for this module. I'm very busy so can't promise any timelines when this will happen. The only thing you can do now is to keep your graphql schema as small as possible by unchecking all the unwanted fields and templates in the module config page. There is supposed to be a way to cache the schema (https://github.com/youshido-php/GraphQL/pull/37) I was planning to look into it. But never had a time for it and thus is not implemented in this module yet.
    1 point
  26. It should be like this { product_single (s: "parent=X") { list { title product_code colors { getTotal getLimit getStart list { // list of colors name // name for each color } } } } } }
    1 point
  27. You shouldn't use it to obtain output in your template file. ProcessWire already comes with the best API to access your content. The purpose of the GraphQL module is to let you access content via AJAX, using JavaScript from client side.
    1 point
  28. @louisstephens Your query should be assigned to query variable. Try to change above code like this $.ajax({ type: "POST", url: 'localhost/pw/graphql/', data: { query: "{ modals(s: \"title=Test-Page\") { list { id title body } } }" // <-- change here }, success: function(data) { console.log(data); } });
    1 point
  29. This one is weird. I just installed the module on Classic profile and Skyscrapers profile with latest ProccessWire. Works fine for me. The "Loading..." is a placeholder till JavaScript kicks in. So this means the GraphiQL js assets are not loading or firing. Could you please try to see if GraphiQL works out of ProcessWire admin. You can either do that manually, using API that exposes GraphiQL in your template file. Or use GraphQL Pages generator. It's in the modules setting page. Looks like this. Just press it and go to `/graphiql/` on your website and show us what you got there.
    1 point
  30. Hey, Rudy! I couldn't fully understand your use case. I guess you want to restrict access to certain entities, like your other site. It is very easy to restrict access to certain ip address. Just before serving GraphQL API you could check for the requested entities ip address and behave accordingly. For example: <?php if ($_SERVER['REMOTE_ADDR'] == 123.234.34.1 ) { echo $modules->get('ProcessGraphQL')->executeGraphQL(); } else { echo 'Access Denied'; } I can't say for sure if that's what you are asking though. If not, please give more details on what you are trying to achieve.
    1 point
  31. Hi @abdus. You are good to go actually. The argument is required only when there is an exclamation mark after it. It does not have to be = false. Sorry for the confusion, the way I explain it in screencast is a bit misleading. To sum it up, if there is an exclamation mark "!" at the end, it means it is required, of not then it is optional. The = false part means, the default value is false. I know, it sounds stupid. It was a bug in the library I used for this module. I updated it to the latest version since the screencast and now it shows correctly. The = false part is actually is a bug in older version of the module. You probably installed the latest version which shows correctly. So, your version is actually is the way it supposed to be. The version in the screencast is a bit misleading, but still correct.
    1 point
  32. I am happy that you like it @Sebastian, thank you for your support. I started the thread here because I thought this would be more like a discussion on how GraphQL and ProcessWire could fit together and wanted to get some feedback first. But this thread quickly become this module's official place here in the ProcessWire forums. Also @teppo included the link to this thread as the "dedicated support forum thread" in the 143 issue of the weekly.pw (which I was flattered to see ). Now I don't really know how to go on with this thread. Should we abandon it and start new thread in the modules section? Or maybe this thread could be moved to modules section? What @moderators think of this? Meanwhile, for those who are following this thread I wanted to mention that there are some additions in the dev branch, such as mutations that allows you to create/update pages and there is also support for FieldtypeMapMarker field. I stopped developing the module for some time because I thought that it needed a good testing before moving further with it and decided to built an SPA using this module, to see if there is something that need to be added or changed. But then I got carried away and started to make usage of third-party APIs such as Wikipedia and GoogleMaps. As a result the app does not make heavy usage of the ProcessGraphQL module, but it is still relevant to showcase the module's abilities. It is a US Skyscrapers app, duh... You can see it live here and the source code here (though I doubt that the code will interest you if you are not a React developer). I was finished with this demo SPA just couple of days ago. Now I will be back to continue to work on this module again.
    1 point
  33. Just to make sure. Is this a PHP error, or is it a JavaScript error in your browser console? Could you also give some environment details. Which version of PHP, ProcessWire?
    1 point
  34. Ooh, that's right. Now I get what you mean. Thank you for clarifying that for me. That's true, with this module it gets available to the public without echoing it explicitly. So you will have to setup extra permissions to make it closed to the guest user. This was the initial intention of this module really. The goal is to build a tool that will allow you to quickly bootstrap an AJAX api of your ProcessWire content to build SPA out of it. For cases like you guys describe, this module might have some drawbacks. But you could always cook your own GraphQL api and make it behave however you want. It's fairly easy after you learn a bit about it. Here is the library I use for this module.
    1 point
  35. There is not need for different endpoint for users with different roles. The module does not have any authentication/authorization logic on it's own. The users that will be able to authenticate with this module are the same users in your ProcessWire installation. When I mentioned implementing authentication, I was talking about logging in via GraphQL api, like via AJAX. In reality it will be the same $session->login('username', 'password'), nothing more. No, no. Of course not. I am sorry for the confusion here. Legal templates mean legal for the api. It does not mean it will make it available to the public. Like I mentioned earlier the module checks if the requesting user has permissions to view, edit, create and etc. If say you select user template as legal. It does not mean it will be public. It means it is available via api to those who are authorized to view it, authorized via ProcessWire's access control system. I personally don't think there is even a need for the legal templates option. But it is helpful if you have too many templates and selecting only few can reduce the schema size and make api faster. I think there is a bit confusion about this. I want emphasize that this module does not make any data public, nor does it anything private. That is not the module's concern. The module's job is to make your data available in a JSON format, in addition providing the ability to consume that JSON data via GraphQL api. If the user does not have permissions to view a certain page according to ProcessWire's access control system then he won't be able to fetch it. The same goes for fields. When implemented the user will be able to access only those fields that he is authorized via ProcessWire's access control. But I will add an option for legal fields also, because that also could help reduce the initial schema size.
    1 point
  36. I have not thought about this kind of security layer. Though it sounds reasonable. I will keep in mind this option. For now I plan to add an option to limit the templates that are meant to be accessible via public api by explicitly selecting them.
    1 point
  37. Are you talking about pages with the status hidden? If thats the case, it should behave as expected. At this point this module accesses content only via $pages->find(). As long as $pages->find() does not return pages that are not intended for public this module should not make it accessible. I do not use $pages->get()as it bypasses some permission rules. As a proper citizen of ProcessWire, one would implement code-level permission check by attaching a hook to User::hasPagePermission, User::hasTemplatePermission or any other equivalent, including field level permissions. For that cases this module wouldn't have to figure out anything, it will happen naturally. But for those cases where access to resources are checked outside of ProcessWire's permissions context, this module might not be a good fit for building service api.
    1 point
  38. You couldn't be more precise! GraphQL and ProcessWire fit each other very well. All this module does is just maps the ProcessWire's fieldtypes with GraphQL type system. It literally tells GraphQL that FieldtypeText is a StringType, FieldtypeDate is DateType and so on. And for getting the data, on average, it is less than a single line of code . Since you can access value of a page field like $pages->$fieldName all primitive fields inherit a method for accessing data from one place. I sure having lots of fun writing this module. I agree with Drupal "godfather" totally. The need for quick bootstrapping of an api service with flexible content structure is in very high demand. I had a hard time landing a job as a ProcessWire developer. So I target myself as a full-stack SPA developer in React.js/Node.js. I tried many of open source REST frameworks in Node.js that would help me get started with a project quickly. But non of them offered enough flexibility for my style of programming (I guess ProcessWire spoiled me ). At the time I figured out the best way to build REST api in Node.js I found out that REST is not flexible either. When an app starts evolving REST gets very messy. The Github built three versions of their REST api and still are not happy with it and now decided to release a GraphQL api which probably will not introduce breaking changes in the future, because GraphQL is designed that way. I think if made correctly, this module could bring a great value to many ProcessWire users. That's right. That is the main goal of this module. I will eventually implement all the features that needed to build a complete SPA with this module. I just try to move carefully and a usage feedback from community would help a lot. Just installing it and making couple queries to confirm that it works as expected would be great.
    1 point
  39. Of course. In one of your templates (edit: In one of your template files) you simply do <?php echo $modules->get('ProcessGraphQL')->executeGraphQL(); and that's it. It will handle all GraphQL requests. There is more info in the repository.
    1 point
  40. Quickly toggle your checkboxes with extra action buttons via AJAX. The module adds functionality to InputfieldCheckbox so you can toggle the checkbox fields in the extra action buttons intruduced in ProcessWire 2.6.5 via AJAX. Github Page Download Link Requirements This module works only for ProcessWire versions later than 2.6.5. How to Install 1. Copy the files to /site/modules/ProcessQuickToggle/ 2. In your admin, go to Modules > Refresh for new modules. 3. Click the "Install" button next to "Process Quick Toggle". Usage Go to any checkbox field you want to enable quick toggle feature for. Setup > Fields > my_checkbox_field. There in the Input tab you should see an Enable Quick Toggle field. After you check it you will see some fields that you can fill based on your needs. Then save the field. Now there should be an extra button for every page that has this field in the Pages tree. Features Supports template contexts. Supports core FontAwesome icons. Any kind of feedback is appreciated.
    1 point
  41. Made a little patch (0.1.1). Now it checks if the field is editable and if the page is locked before showing you the button. I was about to submit the module into Modules directory, but then I encountered the ProcessWire version compatibility field. The highest option is 2.6 and this module supports only 2.6.5 and higher. Can anybody confirm that I wont be able to publish it until 2.7 ?
    1 point
  42. That's not entirely correct. If you don't check the "active" checkbox under Settings when editing a page, the page is not listed for users with this language, e.g. excluded from $pages->find calls. I'm not sure what the default behaviour is when you visit the page directly in a language which is not active. Maybe you'll see the content in the default language. In this case, I'm sure you could also hook into somehwere and throw a 404 or do the prefered action. Yep. You're right. I did not even know that. I guess the difference with this module is only the contextual approach to the multi-language sites. I don't think this module is any better than the core LanguageSupport module, just the other way of doing things. I posted it here for community to decide. If we decide we don't need it the thread will stay only for historical reasons I guess. Another thing might be the hassle with FieldTypes that do not support multi-language. FieldtypeFile and FieldtypeImage for instance. I know that you can have multi-language descriptions. But what about files themselves. You can't have different files for different languages.
    1 point
  43. ProcessWire does not support tree based multi-language sites. This is just another approach to handle sites with many languages. Some people prefer to do it this way. There are cases where websites have 600 pages in english, 700 pages in russian and only 300 pages in english and russian. In this case it is much better to keep the content separate, each under one section and have their translations linked. In case for core LanguageSupport module. When you publish an article in english, it will be shown in the russian version of the site too, even if there isn't a russian version of the article. It will also will show in places like navigation, on sidebar with the latest news etc. However if you put everything english under one page and build every parts of your site under that page (your navigation root, latest news) then your article in english language will never be seen in russian version. Update: The last paragraph is not entirely correct. See the comment by @Wanze below.
    1 point
  44. If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file: ini_set("session.gc_probability", 1); ini_set("session.gc_divisor", 100);
    1 point
×
×
  • Create New...