Leaderboard

I feel like 580px for the sidebar is far too big, and that's the minimum. I feel like 380px would be far more comfortable. The view without the sidebars doesn't have the page breadcrumbs anymore.

@adrian Thanks for all your efforts to this point. I love this community. I try to help where I can as well.

When I click that link I download a processwire.zip (10mb). You have to extract the content of the zip maybe first?

Thank you @teppo! I knew I can count on you!

Moved

I am quite happy with translation options included in PW. Translatable strings like $out = $this->_("Live long and prosper"); // syntax within a class (modules) $out = __("Live long and prosper!"); // syntax outside of a class (templates) are useful for modules and (rarely) in the template system. To make them accesible globally I define a page property in my _init.php file which is prepended to each template. /** * define globally used translatable strings here */ $page->__read_more = __('Read more'); $page->__submit = __('Submit'); Furthermore I use some language related functions (language specific date and time formats). These functions are placed in _func.inc which is included by the _init.php // Include shared functions include_once("_func.inc"); Everything else is content and should be stored in multilanguage fields. (text, textarea, optionselect)

Hello cstevensjr. I Agree that this was very interesting. I ended up using this line at the beginning of my config.php file of my sites before any config options. setlocale(LC_ALL, "sv_SE.utf8", "sv_SE.UTF-8", "en_US.UTF-8", "en_US.utf8", "C.UTF-8", "C.utf8"); That made the error message disappear for me and has not come back. As matjzap explained, this makes PHP try all the locales I designated until it finds one that is installed. Then it will use that first locale that it finds. I would like to again thank everyone in the PW community that helps me understand this problem and solve it. You are the best. /EyeDentify

So the fields are named Tab1...Tab9 resp. TabContent1...TabContent9? In that case, two possibilities immediately come to mind, but both require you to assemble the name outside of the quotes (there might be a way inside the strings, but I can't think of one right now). <?php //... $tabname = "Tab" . $i; echo "<label for='tab{$i}' class='labeltab'>{$page->$tabname}</label>\n"; Or, in one go: <?php //... echo "<label for='tab{$i}' class='labeltab'>" . $page->get("Tab" . $i) . "</label>\n";

This week we have a new core version on the development branch and some nice updates to our Uikit admin theme in development. This post covers them in detail, includes a screencast and links to a live demo of the updates. https://processwire.com/blog/posts/processwire-3.0.56-and-uikit-admin-theme-updates/

For ckeditor there is already a Maximize plugin in aos (ckeaddons). As for the other fields the biggest issue is the button placement, or finding another solution to trigger. I think such features would fit to the drop down idea I plan to add to field labels - when my time allows

Here's a JS demo: https://jsfiddle.net/abdennour/oh3jL82j/ Not knowing your exact scenario, but I think a purely JS solution would be better unless you have a LOT of children that you are doing the getRandom on. If you really want to go the AJAX route we can help you further, but it's really a PHP issue, rather than PW so googling around would be pretty helpful. The only catch with PW and AJAX is that the URL for the ajax request can't be directly to a php file in /site/templates - the file either needs to be outside /site or you need to assign the file to a PW template and page call the url for that page. Sorry for the short answer - I am a little rushed at the moment.

Because your click action is client side (javascript) and the getRandom is server side (php), you will either need to get all the options initially and do the random filter using javascript, or you would need to do an ajax call on each click and return another set using getRandom. Does that make sense?

Welcome to PW! Use the autocomplete inputfield: http://modules.processwire.com/modules/inputfield-page-autocomplete/ Let us know if you have any problems with it.

EDIT: Solved this by myself, see bottom of the post. Hi @adrian First of all, this is a really great and useful module. I want to submit the id of a page to my custom module, but I don´t want to show up the id as a field that is being shown. Right now I call the module via admin-actions/options?action=BewerbungsunterlagenAnfordern&id=1514 And this is my defineOptions function protected function defineOptions() { $missingFiles = array(); foreach ($this->pages->get("/unterlagentypen")->children as $unterlage) { $missingFiles[$unterlage->id] = $unterlage->title(); } return array( array( 'name' => 'missingFiles', 'label' => 'Fehlende Unterlagen', 'description' => 'Wählen Sie aus, welche Unterlagen noch benötigt werden.', // 'notes' => 'Only use one of "Pages" or "User Roles"', 'type' => 'AsmSelect', 'options' => $missingFiles, 'required' => true, // 'requiredIf' => 'pages=""' ), array( 'name' => 'id', 'label' => 'ID der Bewerbung', 'description' => 'Bitte den Inhalt dieses Feldes nicht ändern.', 'type' => 'Text', 'required' => true, ), ); } How can I hide the ID Field? Just set the type to "hidden" and Voilá

I've tested in PW 3.0.42 and it works as expected. Unpublished pages are not returned, whether I am logged in as a superuser or not. Seems there's something else going on in your install.

Since the informations are really spare, any chance to have a look at that? Or a db dump?

No worries @adrian Anything I can help - shoot straight. Helping one is helping the rest so I am sure the gratefulness is to follow. Especially when it is supported with the latest versions etc.

A Followup This was an interesting conversation by all parties. What I didn't get was what actual syntax that was put in the /site/config.php file. While this may not matter to more experienced users, it makes a difference to others. My sites don't use Multi-Language and I was still confronted with the error that @EyeDentify noted in the original post when updating an existing site to ProcessWire 3.0.55 This is what I put in the /site/config.php file to make error go away /** * Installer: SetLocale Setting * * This is now needed since ProcessWire 3.0.53 to set local information * */ setlocale(LC_ALL, "en_US.utf8"); As @matjazp stated, it doesn't really matter where in the file this goes. What was confusing to me is that most other settings in the /site/config.php file started with $config and it wasn't clear whether this setting needed to follow that style. As I said, it may not be important to experienced PHP users, but knowing what to put when confronted with this warning is helpful. As an aside, it would also be helpful to know the exact syntax that is needed if using the init or ready files. Maybe I have missed something in reading all this that should have been clear to me and excuse me if I have. If what I have used is incorrect, I ask that someone provide the correct format (styling). Thanks.

@MilenKo Ok, just committed new versions of Migrator and also MigratorWordpress so be sure to update both. Comment dates now working and also fixed an issue with comment status from last commit. I'll look into the comments/tags and homepage issue tomorrow - gotta run

v134 has a new option for FileFieldTweaks: disable filename truncation for File fields. Thanks @BitPoet for the right track and @Robin S for the request. This was something bugged me for some time but was lazy to investigate

I agree with you on that. I think it would be best if we move this thread to modules section. So, please move it to the modules section. Then after I will update my first post of this thread a bit and add a module tag I guess

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.

it would probably need to be part of a site profile so that it could make sense, it also integrates with 3 other modules, ProcessGeneralSettings, SimpleSiteEngine and SimpleSiteMeta, which together complete the whole frontend api that i'm trying to develop...

sure, so the (currently named) SimpleThemeEngine is basically a front end api, which is now in module form, but was previously a loose collection of functions that were used procedurally. I would probably recommend to use Spex since it released and proven to work; My module is probably too specific for general release at the moment... It uses WireData class for storage and provides methods for: Adding, manipulating assets (css/js) outputting assets (css/js) Getting and setting theme variables/settings (used for layouts, like show/hide page header, etc) injecting inline js code in head/foot simple web fonts management, loading etc injecting markup into parts of the page (sort of layout hooks) problem with releasing module is that it depends currently on ProCache being installed (future version would have setting to select the caching/min engine, e.g. AIOM or PC)... below is an example of the code that would be used in the head.... // $ste = $modules->get('SimpleThemeEngine'); echo $ste->headAssets(); echo $ste->getJsConfig(); echo $ste->gFontLoader('Open+Sans:300,400italic,400,600,700|Montserrat:700'); echo $ste->getInjects('header');

v133 contains a new CKE plugin Code Snippet which lets you insert rich code snippets with syntax highlighting into the editor. The plugin uses highlight.js. On the frontend you'll need to include highlight.js assets and initialize (see more at higlightjs.org): To customize the languages available for selection and the theme, add this to /site/templates/admin/cke.js file (this is the auto-loaded configuration file for CKEditor, you can modify it in the Asset Paths section in AOS): CKEDITOR.editorConfig = function (config) { config.codeSnippet_theme = 'foundation'; config.codeSnippet_languages = { apache: 'Apache', css: 'CSS', html: 'HTML', ini: 'INI ', javascript: 'JavaScript', scss: 'SCSS', php: 'PHP', sql: 'SQL', }; };

For someone just coming in from the Wordpress world it is tempting to look for a module/plugin that does everything out-of-the-box to avoid having to learn about the form API, hooks, PW native features, etc. If I have to know all that before I get anything usable, I might as well skip your FrontendUser module + two required helper modules that may or may not be compatible with the latest PW version and just use those PW native features to put my own solution together.

Getting just the folder means $file is actually not a file (Pagefile), but a Pagefiles object. File fields are internally always handled as list of files, so you might need to use the following or alike: $file = $upload->file->first();

If the details are not covered by an NDA, maybe you could share them publicly in this very topic

TLDR: Buy ProFields I don't understand why that brief list of fields is a "mess and a nightmare". I know the general advice given is to reuse fields where possible but I think people sometimes take this suggestion a bit too seriously. Create the fields you need and forget stressing about whether you have perfectly optimised the reuse of fields. If you have less than, say, 100 fields in your site you really have nothing to worry about. I think I saw a post recently where Lost Kobrakai was talking about a site of his with over 800 fields. But ProFields... You mention client editing experience, so I take that to mean you (like me) earn an income from developing websites. With that in mind here are some things to consider when making your decision whether or not to purchase ProFields... Have you thought about how lucky we developers are that we can earn an income with virtually no overhead costs? With so much fantastic open-source software made available to us at no cost we are in a very fortunate position. We could design and develop websites entirely with free software if we so choose. Hell, if we wanted we could go to the landfill and probably pick up a free old computer that would be perfectly adequate to develop a website on. Now think about the carpenters and dentists and all those other professions that must purchase real physical tools (that wear out) in order to earn a living. £100 doesn't go very far if you need to buy a table saw. On the topic of open-source, think about what Mr Ryan Cramer has provided us with in ProcessWire. People with his level of skill do not need to be contributing their time for free to open-source projects - they are in very high demand for all kinds of lucrative work. Purchasing a Pro module from Ryan is a way to show appreciation for the generous work he puts into PW. PW is not just great free software, it is great software full-stop. You mention previously having worked with Drupal and Craft CMS. Time is money, so think of all the money you have saved by the quick development workflow that PW allows vs Drupal. And Craft CMS costs USD$299 per website and is still not as powerful as the PW core. Ryan's Pro modules are insanely good value for money. The price that you can purchase a dev license that allows you unlimited use of the modules is more than reasonable. For comparison, here is one of the most popular addons for Concrete5: http://www.concrete5.org/marketplace/addons/block-designer-pro There is no unlimited license, and a license for 5 installations costs USD$276.25. And it requires "Block Designer" so that's another USD$120 for 5 installations, bringing the cost to USD$396.25. I haven't used it but it looks like it is basically the equivalent of Repeater Matrix. But probably not as elegant. And with ProFields you get another four modules bundled in. For unlimited use. For USD$129. Hope this has helped make the decision a little easier.

Thanks for this very useful fork! It would be rad if it integrated @flydev 's fork too for hashtag search!

No issues here with the scroll (Chrome/FF). I have plans to modify the field edit link tooltip, then I'll try to make them work in repeaters too, and perhaps add a template context feature too.

You are completely right. I can't argue that "enabled-by-default" approach can lead to lots of security issues. That's why I am limiting the exposable pages only to selected templates. While the selector option is quite simple to implement I don't want to enable this kind of option because I believe it should not be this module's concern. The way I see it, if this module stays consistent and retrieves data only through $pages->find() api (or it's equivalent like $page->children(), $page->siblings() etc) that should give the user any type of control with the security. For example what you suggest could be achieved with a single hook. Say this is your template file where you expose your GraphQL api (something like /site/templates/graphql.php). <?php echo $modules->get('ProcessGraphQL')->executeGraphQL(); What you suggest could be achieved like this. <?php wire()->addHookAfter('Pages::find', function($event) { $event->return = $event->return->filter($mySecuritySelector); }); echo $modules->get('ProcessGraphQL')->executeGraphQL(); I would prefer users to approach security this way. This strategy to security gives full control for the user while allowing me to stick to a single rule when concerned about security and makes the code of the module much easier to reason about. I do realize that I could just insert the above code in the module and that's basically an implementation of what you suggest. But I don't want to encourage the user to solve security problems via module settings because no matter how hard I try, I won't be able to make this module dummy proof without limiting it's capabilities. Another thing I wanted to mention is that I see this module as a GraphQL representation of ProcessWire api. Like @Ivan Gretsky mentioned, if done right, this could allow us to build lot's of useful developer tools on top of this module. Even a mobile app that gives you limited site administration capabilities. But only if module is consistent with how ProcessWire behaves. And that includes the security of course. Oh no sir, not at all. I value your opinion very much. That's exactly what I wanted to hear from the community, opinions. I am thankful to you for mentioning this aspect of the module in it's early stage, before I started to implement other features that depend on it, like authentication or others that I might not think of right now.

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.

Wanted to mention that there's a new dev version https://github.com/somatonic/Multisite/tree/dev2 that we are testing and using right now. It was tested and works with multilanguage and PW3 various features.

CMSCritic just launched another part of the site which is a directory of CMS products (powered by ProcessWire of course). Hope you guys enjoy: http://www.cmscritic.com/dir/ While you are there, maybe click the "like" button for ProcessWire if you are so inclined.