Leaderboard

Just checked in a first beta version of a new module I'm working on. Feel free to test out and see what's up with it. Pollino (beta) A simple poll module for ProcessWire This module makes it simple to setup polls for your website. It is based on a simple page setup to create the polls. So each poll is a page, and its children are the answers. Pollino will create the templates and a PollinoPolls page in the root to start with. You can add fields to the templates as you wish and later use hooks to modify the output of the poll. This can be useful, for example, to use images as options or just some custom markup etc. It provides some API to render the poll form and the result. These methods are hookable and it's easy to customize the output if needed. It can be rendered on any page and even multiple on the same page. Pollino takes care of saving the votes and preventing multiple votes. It comes with some configuration settings to choose what method to use to prevent from multiple votings: using cookie and an expire time or by IP and optionally also the UserAgent with and expire time or by logged in User Pollino isn't 100% plug'n'play but it provides a solid foundation and comes with some premade theme and output for you to start. It takes care of the boring stuff and lets you concentrate on the front-end stuff and styling. That's what matters after all. It does support multilanguage, as all strings are translatable in the module. Also since it's using simple pages and templates you're free to add or change fields to make its output multilanguage without much hassle. ----- Read more and download https://github.com/somatonic/Pollino Online Demo I setup a little demo here to see using https://lightning.pw http://titanium-x77.lightningpw.com/ Have fun.

This site was recently launched and has been running great for the last few weeks. It is probably the largest PW project I have done; there is a lot of media to keep organized, this label has about 70 albums and over 400 artists... http://www.newfocusrecordings.com/ the homepage displays 12 random albums the catalogue page, uses datatables and loads the cover images on demand; the filtering is all done with the datatable, and the urls are updated without page reload... the album page: the pw version replaces a joomla version that was used for about 6 years.. and was a pain to work with; some modules: AdminCustomFiles AdminSaveActions AdminTemplateColumns AIOM+ FieldtypeColorPicker FieldTypeSelectFile (for selecting huge media instead of uploading into PW) FieldtypeTemplates (for selecting which template a certain support doc should show on) FormBuilder FormSaveReminder ImportPagesCSV (used to import some of the data from Joomla and Zoo) InputfieldSelectExtended (used to show additional info after a select action) PageReferencesTab PageTreeAddNewChildsReverse (new albums need to be at top of list) ProcessCustomUploadNames (to ensure the asset naming matches the catalog numbers) PageListerPro ProcessRedirects (for some legacy URLS) ProFields TextformatterBBCode (used for formatting of track and album titles with special characters, superscripts, bold, italic) VersionControl HannaCode SiteUtilities - a custom module that controls many helper functions, read id3 tags, move audio files, rename stuff etc.. some forum threads that relate to this project, and as always thank you to everyone who helped and more generally who take part in the forum! https://processwire.com/talk/topic/8366-setup-sharrre-sharing-widget-in-5-minutes/ https://processwire.com/talk/topic/8392-simple-built-in-docs/ https://processwire.com/talk/topic/8350-module-fieldtype-yaml/ I also work for this label, and have designed about 10 of the covers.. - - - - Special Features: Press View There is a user role called press, and on the user profile, site admins can select certain albums to allow access to for that press user. When the user logs in they can see which albums they have extended access to and then when they view the album there is an extended view and additional media and content. The page audio player will play full streams of the tracks, whereas the public view only plays the edited preview files; the presence of the full stream is indicated with a radio/wave icon.. left widget showing some extra content:

PageTable or Repeater should be both fine for variations - can you PM me with your issues? And yes, modifiers are per template - they can be variations if just simple case (like size, color or some other option like that and no unique stock qty). Others: hoping to open beta for wider audience in upcoming days - please subscribe at https://www.padloper.pw if you haven't already

Wow thanks for using this code and thanks for improving it. Well A technique I use for avoid using sessions is a token and send that token with every request. I previously created a "token" field inside the user page. So when the user logs in a token (normally sha1) is created and saved to his token field. So for example you made a login request and the backend responds with this data. { "status" : "ok", "data" : { "id" : 142, "username" : "clsource", "name: "Camilo", "token": "abc123" } } And then you need to update its name sending a PUT request to the corresponding endpoint PUT { name : Camilo C. } https://api.example.com/v1/users/{token}/profile/name in this case {token} would be "abc123" As the token is saved in the user page you can check if the user exists quering by the token $usr = $users->get("token=$token"); As you may notice the token gives you access for seeing and modifying the user, so its better to keep it safe. A rule of thumb is creating a token with a 1 hour valid time. And when the token is invalid you should request a new one in background. Hope it helps

i think the datatable is fine to load the # of rows maybe up to 100, and it will take a while for them to have that many albums; the page is procached and loads fast here, even with the datatables having to parse that table.. gtmetrix reports a 2.17s load time, and it gets a decent speed score.. the page is currently 647kb which isn't bad considering it is loading almost 15 years worth of releases; i could probably optimize the joins and increase the speed it takes to create the cached version; procache reports 5.1094s to create the page, but there is a ton of processing going on, like each album has hidden columns with the filter data, which are page IDs for stuff like album artist, performers, genres and label..

Hello, I created a simple REST helper in order to create REST APIs with Processwire, without depending on external routers Here you go!. https://gist.github.com/clsource/dc7be74afcbfc5fe752c

Hi, After the move to ProcessWire on one of our major websites, I had to build myself a module/plugin so I could use the Amazon S3 / CloudFront infrastructure. The module/plugin uses Amazon S3 PHP SDK and the idea was to provide a clean way to upload/backup files to S3 and distribute the assets via Cloudfront. The current version of the module/plugin will copy the page files to Amazon S3 so you can then serve the via Cloudfront automatically. Note that the files are still also copied to the server where your PW installation resides. There's an option to backup the deleted files to another folder on S3 because when you delete a file on PW via the admin, the file is also deleted from it's folder on S3. The module also supports Apeisa's Thumbnail module so it also stores the thumbnails on S3. Note that the native size() method to create image thumbnails on S3 is currently not supported. As it is, the module will only upload new assets, so beware that if you already have pages created with assets you'll definitely have errors, so my advice is to test this with a blank installation of PW. If anyone wants to test it and contribute to it, I think this provides a good proof of concept for a functionality that is requested by several users (me included). Please note that I'm not a PHP developer, my skills (very) limited and I'm aware that it can be improved and I'm open to suggestions, feedback and most of all, collaborators. The module is hosted on github here and it's available in the ProcessWire modules directory. Nelson Mendes

Yeah, that explains it perfectly. In fact, if I open www.thesharktankproducts.com/products/ I end up at index.php?it=products/. The problem is that you're doing your own custom redirect after ProcessWire has already rewritten the URL to index.php?it=some-url You might want to take a look at ProcessWire's default .htaccess rules. There's similar www redirect there, though it works the other way around: non-www URLs are prefixed with www. The important thing is the position of this rule in the .htaccess file; you'll want to add your custom rule to similar position. Generally speaking, though, redirects like that should be placed as early as possible in the .htaccess file, since that's the most efficient way: you don't want to parse any extra rules, if there's going to be a redirect that makes it necessary to go through that very same process again anyway.

Sorry about that - good point. I think the problem with what you're trying to implement is that @ is not allowed in name fields. This is a bit hacky, but seems to work fine and allows a user to log in with either their name or email address. Keep in mind there will be issues if you have more than one user with the same email address - email is not a primary/unique fieldtype so even though there are checks to prevent a user from changing their email to one that already exists in the system, it is still possible to create two users with the same email via the admin panel if you are setting them up. It replaces any instances of "-" with "@" and checks to see if it can find the user with that email address. If there isn't a match, it processes the name with the "-" just in case there is a user in the system with a name that contains a "-", which is allowed. public function init() { $this->addHookBefore('Session::login', $this, 'beforeSessionLogin'); } public function beforeSessionLogin(HookEvent $event) { $name = $event->argumentsByName('name'); if (strpos($name, '-') !== FALSE) { $email = str_replace('-','@',$name); $u = wire('users')->get("email=$email"); $username = $u->id ? $user->name : $name; $event->setArgument('name', $username); } } I put this together pretty quickly, so can anyone think of any major issues with this?

It's possible to paginate the datatable with AJAX too, though it adds a minor delay of course when you click a page number.

The site is great. One has to be picky to find something to improve)) But I did try: 1) On desktop the "About" page in nearly unreadable as the dont size is small and lines are long with no pictures. Maybe limiting width or adding columns could help readability. But who cares about those "About" pages? 2) Catalog and news paginations are different. The 1st one uses datatable's defaults, the second one is custom made. It could be better to make them use the same style for consistency. 3) I would've changed the ratio of the columns in the catalogue under 480px so the cover takes less space. Or put tthe text underneath the cover. 4) The hover state of the cover pictures in the catalogue looks a bit buggy as the pictures have different widths. I do not know why is that as the covers should be all square. Maybe you shoud limit their width not height? Those are little things you can find on any site if you wanna look for'em.

Definitely one of my all time favorites - very clean, polished, nice typography, mobile and desktop both work flawlessly. Great work Macrura!

@clsource Thank you for your REST helper. I'm using it for a project and it is working fine. For my project I'm using basic HTTP Authetication. I added some code to the params method to fetch username and password and merge it into the $params array. The altered code is here: https://gist.github.com/gebeer/5d1447ff76e17931d944#file-rest-php-L265 For a PUT request I use $session->login() to verify username and password. $uId = $input->urlSegment1; $u = $users->get($uId); if ($session->login($u->name, $params["upass"])) { $session->logout(); //update user data } In the response header of that request I get some PW cookie data: Set-Cookie: wire=ha6io723mkfc9v4scdib3oe8g7; path=/; HttpOnly wire=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT wire=1n8faeiva3vg7u13ijsrs24bt1; path=/; HttpOnly wire_challenge=YK0WRw0Wrd2ZAhKEUCLPOHd9iSySEPb91; expires=Tue, 07-Apr-2015 14:11:24 GMT; path=/; httponly wire=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT wire=u9m41s8b87d3ca1jp1jbl0r6k3; path=/; HttpOnly wire=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT wire=oidcbmht561qnvts2fjnq4b7p3; path=/; HttpOnly persist=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/ Can I avoid that somehow other than not using session? In the PW cheatsheet I couldn't find anything related to cookies.

Just use the labels of templates to name them more descriptively. The buttons below pagetables will always show the label and fall back to the name of the template if no label is defined. For the "add new" buttons, there are a lot of them in processwire. Most of them are there, because either the context provides the information about what will be added or the cms can not tell ahead of time what will be added. You can edit them with hooks, different ones dependent on which one you'll want to edit, but not via the admin backend. But this is not the thread to take about this in detail.

I just committed an update that brings full support for repeater fields (images and images embedded into RTE fields inside repeaters). I also fixed a bug with the new core cropping functionality if you set a filename format that is not available on file upload, such as $file->description. There were some significant changes to hooks and logic to get the repeaters working, so please test and let me know if you come across any problems.

Assuming that the structure of the fields is always the same (Question, Checkbox 1, Checkbox 2), I think that the approach depends on who defines the questions: the user (like a "create your own form" type of page) You (with a fixed set of questions that the user must answer on the page) In the first case, you could use the Profield Table, as suggested by nickie, or even simpler, a PageTable (which is not a Profield): You create a template called question, with the fields question_text (text field), question_answer (text field), display (checkbox field), include_in_email (checkbox field). Then you create a PageTable field questions, that uses this question template. Finally you add this questions field to the target template. This way, the user can add as many questions as he wishes on a page. The second case is more difficult. The "pure" way of doing it would be to create a field for each question's subquestion, i.e children_answer, children_display, children_email, pets_answer, pets_display, pets_email, etc. The problem is that this would create an enormous amount of fields, which becomes inefficient (see this post from Ryan). You could create your own compound Fieldtype to group the three subquestions in one field (see the Events Fieldtype/Inputfield as an example), but this would still require 50-80 different fields, which is a lot. I think that the approach that I would attempt is the following: Create a question template with fields question_text (text field, with visibility set to visible but not editable), answer_text (text field), display (checkbox field) and include_in_email (checkbox field). Create a questions PageTable field that uses this question template. Add the questions field to the target template (let's call it questionnaire). Write a module to hook after Pages::added, so that each time a questionnaire page is created, it adds the question pages under it. Here is an example of what I mean: // Inside a module public function init() { $this->addHookAfter("Pages::added", function($event) { // Activate the hook only if the added page is a questionnaire if ((string)$event->arguments(0)->template == "questionnaire" $this->hookAdded($event); }); } public function hookAdded($event) { $questionnaire = $event->arguments(0); // List of all your questions $questions = array( "Do you have children?", "Do you have pets?", "Do you have rabies?", // etc. ); foreach($questions as $q) { // Create a question page under the new questionnaire $p = new Page(); $p->template = "question"; $p->parent = $questionnaire; $p->question_text = $q; $p->save(); // Add the question page to the questions field of the questionnaire $questionnaire->questions->append($p); } // Save the questions field of the questionnaire $questionnaire->save("questions"); } You should also adjust the permissions for the question template so that a user can't delete them. Yet other approaches would be to create a custom Process module (see the Hello Process Module for an example), or to set up a custom front-end template to answer the questions instead of using the admin back-end.

I'm actually not that big of a backend guy, so maybe it does only seem easy to me. You're right with the database being dependent on fields. I had that wrong in mind. But I still think, that the ability to add additional fieldgroups beyond the "root" one shouldn't be crazy hard to pull of. For me it would also not really matter how this fits any models or if the database uses less joins, I just know that predefined groups of fields and reusing them are something that ProcessWire does not pull of nicely by now. The only thing I'm not so sure about is, if adding a additional layer between fields and templates really is the key to more success (productivity / ease of management / …). Wouldn't we have the case that after including this layer people would come and suggest adding another layer, because they want another level of grouping, and we'll get in some kind of loop.

I don't think that such drastic changes need to be operated, since it is already possible to create compound FieldTypes that group different values. An example of this is the Events Fieldtype/Inputfield created by Ryan to demonstrate how to create custom fieldtypes. The Date, Location and Notes of an event are stored as different columns in a single table, and could therefore be compared to the Component. What would be needed is a good way to create such compound fields in the admin section. As I understand, this is what the Table ProField does, though it is still a little limited, since you can't use page fields for example. But this would tend to indicate that the changes to be done would not be so drastic.

Update: Menu Builder Version 0.0.2 is now available. I'll update the original post later + post a new video. Main Changes: Beta status Menus stored as pages (note: just the menu, not the items!) Menu items stored as JSON in a field in the menu pages (empty values not stored) Add menu items from ProcessWire pages using page fields (option to choose between PageAutocomplete and AsmSelect [default]) or a Selector (e.g. template=basic-page, limit-20). For page fields, you can specify a selector to return only those specified pages for selection in the page field (i.e. asm and autocomplete) For page fields, now you can also add css classes and IDs as you add the items Menu settings for nestedSortable - e.g. maxLevels (limit nesting levels) Advanced features (e.g. add pages via selector, menu settings) currently permissible to superadmins only (may change to be permission-based) Delete single or all menu items without deleting the menu itself Lock down menus for editing Highly configurable MarkupMenuBuilder - e.g. can pass menu id, title, name or array to render(); Passing an array means you can conditionally manipulate it before rendering, e.g. make certain menu branches visible only to certain users [untested and the code is up to you!] More... Note: Some nestedSortable features not yet implemented/working (some are not really necessary actually). The module creates 3 fields (menu_items, menu_pages, menu_settings) and 1 template (menus). Menu pages are stored as children under the modules parent page (admin/setup/menu-builder/) - so not accessible in the frontend Issues: Drag and drop (ordering menu items) is some times finicky...something in the js I think or just my mouse.

I've added and changed a lot of things on the dev branch. It'd be cool if you guys could test the current state to spot issues I have not encountered yet, so I can call it 1.0.0, merge it into master, and then publish it to the modules directory. Thanks! Changes, since the first post: 0.6.x - 0.12.x use noconflict version of ace implement possibility to add built-in extensions, by default emmet is enabled apply major PHP code refactoring 0.5.x enable field to be instantiated via API add interval check on editor.renderer.lineHeight and only initalize everything via callback when it is available add option to enable/disable localStorage make advancedOptions use the the Inputfield itself, INCEPTION! Regarding built-in extensions: They are sparsely documented, there are only two examples here. I have no idea what they all do. Some might even need additional libs, like emmet, which needs the core parser, that I included in this module.

There's a new version available. Now supporting file versioning to handle the caching issues of CloudFront. There's an option on the module configuration that will automatically rename the uploaded files by inserting a timestamp in the file name. This way all the files have unique names and that will make it easier to replace old files already cached by CloudFront (something that can be a huge PITA as many CloudFront, or other CDN systems know well).

@Gabi: this sounded like an interesting idea, so I mocked up a proof-of-concept module (Page Render Relocate Assets) that dynamically alters asset requests to point to another location. This isn't, however, something you should yet consider production-ready. Idea is quite simple: the module just hooks after page render and alters generated markup, converting any requests to /site/assets/ to another URL specified via module settings. Just to be on the safe side this (at the moment) only alters requests that start with a double quote and /site/assets, ie. "... src="/site/assets/..." would get replaced, while "Look at my /site/assets/!" or "... src="http://example.com/site/assets/..." wouldn't. To test this I created a new subdomain and pointed it to my own sites /site/assets/. According to this blog post this should be enough, and so far things seem to work just fine. You can see it in action here: http://www.flamingruby.com/about/. Note that one of the images on that page is (for some CKEditor-related reason) embedded with full URL and thus doesn't get "relocated", but other one (the bike) should point to static.flamingruby.com instead. .. so to answer to your question here: changing assets location would require a lot of work at the moment, but this way you can serve them without useless cookies etc. as long as that's what you're after. If you're looking to share the load between multiple servers or something like that, this alone won't do the trick (though if combined with some kind of server-side replication that would be quite possible too.) I might have to take this module a bit further at some point, I'm kind of starting to like where this is going