• Content count

  • Joined

  • Last visited

  • Days Won


Soma last won the day on June 30 2016

Soma had the most liked content!

Community Reputation

6,093 Excellent

About Soma

  • Rank
  • Birthday 03/31/1975

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    SH, Switzerland

Recent Profile Visitors

33,764 profile views
  1. I?m not sure I understand the problem. The "News" entry has a class "active" as it should, but it doesn't show the children as they're hidden dropdown. Seems more like a problem with your html css js.
  2. Module

    Not sure why you need to rewrite it. Current last version is the essence of 2-3 experience using it. Just wanted to mention that for good reasons the module doesnt hook page path anymore cause it creates all sort of problem with core and other modules. Also id based root isnt tranportable thats why i have done it via config and page names. Good luck.
  3. Module

    Ah yes. No problem, I found the issue. My older Multisite module, which was hooking and altering page paths is the problem. Thats why I removed it from Multisite.
  4. Module

    I'm just trying the module. Thanks for the awesome tool. I tried to import the with edit imported content option after, but after some time I get a error "Missing required ZIP or JSON Source" and nothing has changed. After trying again without the option to edit, the pages are all flat imported under home instead of creating the structure. Edit: Every page in the json has: parent_name: "/"
  5. You're all wrong and most only work with entries already added and saved to the pagetable. It doesn't work for when adding a new item, cause the new entry page isn't saved yet to the pagetable field... Only easy way is to store them as children, so you can check for the parent. But storing the entries in a different place there's no way to tell in the newly created entry what source page it is going to land in. I created a github issue 3! years ago and never got a single response from Ryan... The solution I came up with was to store the id in the session and transfer that over to the page edit of the entry, Since I had not autoname feature enabled there, there was a step in between where the entry page isn't even created yet. Kinda hacky but worked. The other issue I got with PageTable also never got answered
  6. Yeah it has most likely to do with valid children method. Can you test this I will have a look at it later and finally make an update.
  8. You can also do $f = new Field(); $f->setArray([ 'name' => 'field_label', 'type' => wire('modules')->get('FieldtypeWhatever'), 'tags' => 'tag1 tag2', 'label' => 'Field Label', 'columnWidth' => 50, ] );
  9. How does the date field work? I get "Not valid resolved type for field \"datetime\"" datetime being the name of the field in my case. Edit: Forget it I'm dumb, forgot to allow the field. It's unusual to not have access as superuser. But the error message is a little missleading Edit: Lol hmm I added it to allowed fields and still same error. System fields "created", "modified" work fine. Also if you only want to get one specific page is it correct to do for example a { basic_page(s: "id=1001"){ list{ title } } } or are there any other methods? Edit: Something else would be image Pageimage is there any support for creating sizes? I see there's something but I don't understand it yet. Edit: Ok I got it. I have to enable "size" for image first images the it work nicely: ... images{ size(width: 150, height: 0) { url } } ... So we can request a size that doesn't exist and it will create it if we have rights to do so. Thats would be pretty cool. Would be crazy to allow some stranger creating 1million sizes through public API . But still if one has write access it is possible, but maybe thats no real issue. I'm still trying to grasp the concept of graphQL and your implementation in PW. So every new Fieldtype and InputfieldType would have to be implemented to work with graphQL?
  10. Just playing around a little with it and it's amazing having a blast. Just wanted to mention I got caught by a redirect scenario and language stuff. If you have multilange installed and configured to have language segments "/en/", "/de/" ... so trying out ajax requests to "/graphql/" would redirect to "/en/graphql/ " but you get a response: {"errors":[{"message":"Must provide an operation."}]} So it took me a while to figure out and was looking at the query instead. Doing the request to "/en/graphql/" works flawless. I was testing the languages and the graphql pages you create don't have alternative languages active. This also might get you caught, when graphql is installed when there is more than 1 language set up. Permission so far seem to work. The template access setting seem no to be inherited, I guess that is intentional? I may have missed it and it was mentioned. Then I'm sorry. – Like in a default install "home" has guest view access enabled, so all pages inherit that (unless you set it no to). But I had to give basic-page explicit guest view access to get querying. I think it's ok to not have all templates inherit access for graphQL. Thanks and keep up the good work!
  11. @Nurguly Ashyrov awesome cast! Thanks for making all this and taking your time to make it awesome This is really cool stuff and opens up a lot of possibilities.
  12. Searching larger page sets can be critical in PW. I had experience with 100'000+ articles that searching 3-5 text fields suddenly takes 5-8 seconds (this is on a very fast server). Reducing it to 1 fields only would take 0.1s. But how would you go if you want to search multiple attributes and all. So for a product site I only have experience with 2-3000 artikels that already takes 2-3 seconds to search and an index ain't going to help here. So PW comes to a limit very quickly when searching large sets with multiple fields. It just creates lots of joins that can hurt your search. Also importing and handling such large sets can be very time consuming. I have a site where 45'000 members need to be snyched every day. Doing that with the API takes around 45m+ and takes lots of memory quickly. It has to deal with loading comparing, creating objects and may produce lots of work for the DB. Compared to have a CSV directly imported to a table would take a couple seconds.
  13. Module

    One of my older module just got some love! So, just wanted to mention that the Module was updated to v2.0.0 with some changes. 1. Its now compatible with PW2.4+ and PW3+. 2. Some changes were made to how it works. It was replacing core function to create the page list labels thus some newer features were missing. Which was kinda pain in the ***. Now it's just hooking after and prepends the image. Done. 3. It also now is not enabled/configured through the template custom label anymore. You can configure templates via a textfield on the modules configuration screen. Just enter template names along with the image field you wish to use: basic-page,image Or basic-page,image.landscape document1,image.portrait 4. It now supports also FieldtypeCropImage (v1) FieldtypeCroppableImage (v2) FieldtypeCroppableImage3 (v3) ... Thanks @adrian for the patience to fix some old problem, and give a hint at new PW3 menu issue. Strange looking at it after years
  14. We started using mustache template engine with PW. Since mustache is implemented in various languages. Currently I can render anything either server side or client side with js or php and both share the same code base. Data can be either objects arrays or json whatever you like. We also use patternlabs node mustache version for prototyping and so all patterns can be used 1:1 in PW later using some simple controller system based on Classes that extend PW WireData so all API can be used. We also use terrificjs for easy modular js components. So no vue or react but just to mention that there's everything possible in PW.