Leaderboard

Major speed improvement ! I have been in dialog with the Tracy core dev (David Grudl) for the last few hours and he has come up with a way to have all the advantages of the current version ("Master") of the Tracy core (including the AJAX bar), without the potentially huge speed penalty - the old ("Legacy") version was always much faster. On some servers, the new version was painfully slow at times. For those interested, the slowdown was due to the use of $_SESSION to store the content of the debug bar. This was sometimes huge (especially will all the custom panels this PW implementation has). This new version doesn't use sessions for the main bar and because the AJAX bar doesn't show the custom panels, the size of the session is kept MUCH smaller. This is brand new, but so far I don't see any side-effects, but please start using it and let me know if you come across any problems, or just feel free to comment on how much better it is! Maybe even drop David a thank you if you feel inclined.

I wouldn't start by installing a Module such as Blog etc. I believe for you, a better approach would be to gradually build your own from scratch. You'll learn a lot more that way. Start with a few individual pages based on a template called "blog-post" and add a few basic fields. Just title, summary and body would be fine. Once you can make and view them then try to create a blog overview or homepage displaying the title and summary of each and a link to each full post. Lets say that template is called blog-posts (plural) You'll get a real kick out of just being able to do that and you're just echoing simple tags and getting to know "foreach" statements. Then try to add a date field to each blog post and add that to both templates. Later you can try adding a main image, maybe even an author and then move onto tags and categories. I think you'll get much more enjoyment out of building your own and a better understanding of the fundamentals.

Just wanted to report back in case I can save anyone else an hour or so. After bashing my head against this I finally tracked it down to domain restrictions on some of the Vimeo videos. In my test env I was using Youtube and Vimeo links from my personal account (no embed restrictions). In production we were using Vimeo links from a colleagues account — they all had domain restrictions set. Removed the restrictions, and waddya know, it works just fine.

Starting with the modules or plugins, despite being productive initially, causes more issues in the long run. This is also, I think, the major disadvantage of WordPress. Majority of the backend is inaccessible to beginners, and the core is obnoxiously complicated. How can showing some posts be so difficult (you know, "the loop"). This forces you to use plugins over plugins and the only thing you learn in the process is how to prevent them from spontaneously disintegrate. I agree with what @Peter Knight said. Even though there are modules for most scenarios, I enjoy recreating those modules by hand, because I get to practice coding and explore new/better/faster approaches, and I also get familiar with the inner workings of ProcessWire. Maybe in the future I'll get bored of building things from scratch but then I'll have built an array of modules, templates, snippets, and will know exactly when to use which.

This fork of AdminBar (https://github.com/teppokoivula/AdminBar) can be very useful in this situation. Style it to match your site and it's a very quick way to give logged in users the ability to edit and add new child pages. It won't ever be as flexible as building your own frontend form and processing using the PW API, but it's very easy when you have complex forms to reproduce, especially if there is image upload and ASM type select fields to reproduce. This screenshot shows that you can add a "New +" child page when viewing the main portal parent. This screeencast shows editing an existing entry:

I enjoy using custom API variables in my templates. One of my usual setups is like this. // ready.php or _init.php $v = new \stdClass(); $v->class = "template--$page->template"; $v->{$page->template->name} = new \stdClass(); $v->scripts = new FilenameArray(); $wire->set('v', $v); Then at any time during template render I can add scripts using $v->scripts->add() or body class with $v->class .= "one two three", and render in my main layout. It's useful because you can always access it from templates, without needing to inject it with $files->render('template', $data) You can set it and extend with anything: a utility class, a simple array, a flag One disadvantage could be that since held in RAM all the time and injected to every TemplateFile instance, you'd need a slightly larger amount of RAM for large objects. Shameless plug: I wrote a blog post on this topic which details the points I've written above. Injection feature is for setting the current ProcessWire instance to an object. Not really needed unless you're working with multiple instances

Lots more updates today. 1) I have changed the default zIndex of the debug bar panels. In the Tracy core they are set at "20000" and go up from there as new panels are displayed, but these were always above the PW dropdown menus which meant you always had to close a panel to access menu items - very annoying. I have set them to "100" as a default, but this is also now configurable in the module settings so if you find you are having problems (especially on the frontend of your sites), you can adjust as needed. Please let me know though if you think there is a better default than 100. 2) Now if you are editing a field, template, or module in the admin, the Console panel will have access to: $field, $template, or $module, respectively which will be the object for the currently edited one. So if you are editing the "body" field, instead of doing something like: d($fields->get("body")); you can just do: d($field); 3) Again, when editing a field, template, or module, the ProcessWire Info panel now contains a new section at the top with details for the edited object. This is an example of the "body" field being edited. 4) The ProcessWire Info panel now uses the exact name of the PW property, rather than the old capitalized and spaced label. This means you can see what you will need to use in your templates to get a certain property. Cheers!

Page Path History Central Manager Manage all page paths history redirects in a single locations. This module is user interface for the processwrie PagePathHistory module, that creates redirects automatically every time a page is moved/renamed. These redirects do not contain regex's and they will not redirect a user away from a published page making them safe for not technical editors to create. Features Include: Ability to create new redirects Ability to remove old redirects View all the automatically created page path history redirects in your system, and delete any ones that no are no longer needed. Git repo: https://github.com/hagcin/ProcessPathHistoryCentralManager Viewing all existing redirects: Adding New Redirect: Tested on: Processwire 2.6, 3.0 Install Install the module PagePathHistory from within the Processwire admin. PagePathHistory is included in core but not installed by default. Install the module ProcessPathHistoryCentralManager by cloning this repo into site/modules/ in your processwire install. Install the module in the admin interface. You can now manage redirects under setup > page path history central manager Similar to and is compatible with PagePathHistoryManager which lets you manage page path history redirects on a specific page on the settings tab.

Ok, after a brief Teamviewer session, it turns out that the problem is beyond PW and @zkriszti, because through neither phpMyAdmin nor adminer could we access the mysql instance. PHP cannot communicate with MySQL server at all. Either the MySQL server does not run on the localhost, but on a different server on the network, or it's not running, which I doubt, because the hosting seems to be shared, so that would mean no service for a lot of sites. Contacting the provider seems to be the best option.

This is the entry I'd be looking at (screenshot below). Make sure you have debug mode on, and having Tracy installed may also help because it should report on errors in AJAX requests, although it may not be a PHP error, but rather an ill-formed JSON response, which is why you should also check out the response tab of that file in the screenshot.

Solved the issue: I had to delete the data that was in assets/cache/FileCompiler/

The culprit is ProDrafts. As soon as that was installed the image field started malfunctioning if it is outside of a FieldsetPage. So the FieldsetPage in PW version v3.0.77 and the current latest ProDrafts module v0.0.6 conflict.

When debugging something like this (for a possible bug report) it's best to do it on a new PW installation on your localhost - you don't want to be messing with your actual project installation. It only takes a few minutes to do a fresh install for testing purposes.

Still works for me... You're testing this with no other non-default modules installed apart from FieldsetPage?

@suntrop, I've updated my hook to include sorting by labels wire()->addHookAfter('ProcessPageEdit::buildFormSettings', function (HookEvent $e) { $page = $e->object->getPage(); if ($page->template != "my-template") return; $templatesField = $e->return->children->get('id=template'); $templates = $templatesField->getOptions(); // sort first asort($templates); foreach ($templates as $tid => $tname) { // remove incompatible fields $template = $e->templates->get($tid); if (!$template) continue; if (strpos($template->tags, 'my-template-compatible') === false) unset($templates[$tid]); } $templatesField->set('options', $templates); });

Based on @bernhard's suggestion, you can combine template tags with ProcessPageEdit::buildSettingsForm hook and remove any template that doesnt have a specific tag. Start by adding a specific tag to each template you need to show, say `my-template-compatible`. Then add this hook to ready.php wire()->addHookAfter('ProcessPageEdit::buildFormSettings', function (HookEvent $e) { $page = $e->object->getPage(); if ($page->template != "my-template") return; $templatesField = $e->return->children->get('id=template'); $templates = $templatesField->options; foreach ($templates as $tid => $tname) { $template = $e->templates->get($tid); if (strpos($template->tags, 'my-template-compatible') === false) $templatesField->removeOption($tid); } }); When you edit a page with `my-template` template, you'll see that non compatible templates wont show up.

I'd be inclined to use Menu Builder in that case, in terms of seperation of your menus, if that's what this is about. To me, I feel that setting page visibility just for the purposes of menus is a tad overkill (keep in mind that I've never had to hide a page from lists and searches before). That said, your structure could be very specific, and I may be missing something here...

@EntitySelf @cstevensjr @abdus thank you all for taking your time trying to help me. I have contacted my hosting provider, and refer back if I get any information of interest.

What we can deduce: - It is not your site - It is not likely to be a vsync issue (can't screenshot that, I am 99% sure) - It is vertically, not horizontally (vsync issues) - I don't think it is extra HTML / CSS inserted by an extension because the way it is distorted (through the middle of a text line) - It happend after the latest Chrome update - Other browsers work fine, so its Chromes rendering - It doesn't happen for everyone (not for me at least, no hits on Google). Did you try - Turning Hardware acceleration back on - Chrome incognito mode (no extensions)

Based on that thumbnail URL I'd be looking closely at ProDrafts. You could try a clean installation with only ProDrafts added and see if the fieldset issue is reproducible.

I think I have things set up the same as you and it's working... Repeater fields (title visibility is set to "hidden"): Hook: $wire->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'repeater_test_repeater') { $title = 'No pages selected'; if($page->test_page->count) $title = $page->test_page->implode(', ', 'title'); $page->title = $title; } }); Result: Tracy Debugger will be helpful in debugging what is going inside your hook.

Install the Admin Custom Files module. On site/templates/AdminCustomFiles folder create a css file named ProcessPageEdit.css and add the following code: .InputfieldImageButtonCrop { display: none !important; } Then on the Admin Custom Files module settings at the "Activate for process" section select ProcessPageEdit, (Page Edit).

A bit more about this...

As far as I recall, today as a literal only works in database selectors, i.e. calls to $pages->find and the likes, not in operations on WireArrays. Not sure if this is documented anywhere though.

I'd love this: - remove masthead - sidebar (left) always visible - change icons to uikit3 icons - breadcrumb on top (with search on the right which i forgot here) - some design fixes Some live changes:

That's the normal behaviour. Have a look at this thread for a solution:

Will do.

OK, so the host provider told me that I had done something wrong (had chosen the wrong server) when creating the database, then just a minute later they informed me that they have corrected the error. (?) This made it possible to log in to phpMyAdmin, and import my db without any problems, but the frontend was still inaccessible giving me 404 error (as far as I got it, it was some kind of mismatch between index.php and config.php). No magic helped there, so I deleted all the site files via FTP, then reuploaded them. Of course, here I needed to modify config.php accordingly (as I reuploaded a localhost installed site). After this step, my frontend came alive & working. Still struggling with some minor issues, but that is for another day.

@SamC - You can configure the module the way you like under Modules > Configure > AdminThemeUikit Also @tpr - updated the AdminOnSteroids module to fix the hotkeys now. Thanks @tpr!!

My issue is that if a FieldsetPage is within the same tab as an image field, the image field won't upload. The image field is outside of the FieldsetPage. If my image field is inside a FieldsetPage, it works fine like yours does.

I've just uploaded v1.6.1 that contains the CKEaddon config fix and also some minor AdminThemeUikit fixes. I've also modified ListerTweaks to allow empty asmSelects. I'm not sure about this line but I guess it's needed to clear previous lister sessions.

I haven't noticed slowdowns (or perhaps I blamed my own code?) but good to know that there's less chance now to see them in the future

Final Update: I reinstalled 3.0.77 and went module by module. The issue is caused by using the new Fieldset (Page) module. I was really looking forward to using this new feature. Unfortunately enabling that module has an effect on image fields within tabs. I was using a Fieldset (Page) field in the same tab however moving it outside of that tab group did not solve the issue. Something that still has to be worked on I guess. Can also confirm that by uninstalling this module, the issue disappears. Bummed. This Fieldset (Page) module looks fantastic. Thanks everyone for their help!

Okay, landed up using a custom style set, and realised that one needs to actually click on the "ul" tag in the status bar in order to correctly select the list and apply the style.

This module both lets you create new redirects that never existed, and delete old redirects one would no longer like to have operational any more. The user story for this project was: "As an SEO specialist I want to be able to manage redirects for news articles without developer involvement." Giving them a simple tool that did not require knowledge regex seemed like the safest way to not have future developer involvement.

Did you check installed extensions? I know this glitch does not seem like an extension issue but you never know...

Fair point, though Ii'm specifically speaking within the context of learning PHP in general. In most common cases, PHP 7.1 is no different to the others.

I use ConnectPageFields and it works on the latest version. Let's say you have 50 types of fish on your site. You add a new book and reference all these fish to that book. If add a new fish and you want to reference it to that same book you would also need to edit that book. With bidirectional link you reference the book when you add the fish. No need to go to the book afterwards. With a few fish and books that's would not be a problem, but if you have more of 50 of each, this would make you live easier. With a bidirectional link both references are visible on both pages in the admin. If you delete one, the other will also be deleted.

I would start looking for JS errors in the console and in particular for the ajax called image upload file on the Network tab. Make sure you disable cache on the console in Chrome.

@The Frayed Ends of Sanity $pages->addHookAfter('LoginRegister::buildRegisterForm', null, 'changeHeader'); function changeHeader(HookEvent $e) { $form = $e->return; // setting $form->description to false, null or "" (empty string) removes it from the form; $form->description = "Header text"; $e->return = $form; } in ready.php https://processwire.com/api/hooks/

Many thanks for your comments. I've read through the links you all posted and they have been very helpful. I will start working through the tutorials. I was intending to learn PHP some years ago, but never followed through. This now gives me an opportunity to make that a reality. Is there a specific version of PHP that is recommended? I have a book that teaches v5.2. Many thanks, after checking through the settings your guess was correct. I did a cleanup and reinstalled with the demo files and now everything appears fine.

The page tree in the sidebar can be a little inconvenient at times, when the sidebar is small and the action buttons span on multiple rows or on mobile devices. I made them open in a drop-down on click. Here's a codepen.

Reinstalling did the trick.

I completely agree. As much as I think whitespace/padding is important, I still prefer the default theme in this regard. I also think that the size of <h1> tags needs to be reduced significantly - it makes the title when editing a page huuuuuuge! Actually, can we go back to the default theme here also - no need for the title - just put it back in the breadcrumb and put the save/publish buttons on the same line as the breadcrumbs too. These are big showstoppers for me at the moment. The top of the Content / Children / Settings tabs is 215px down compared with 113px. That's 102px of wasted real estate at the top of the page! BTW - I really do like this new version of the UiKit theme - nice work Ryan Another idea I have - what about having the off-canvas menu (accessible from the PW icon) look like the sidebar menu on large screens. I don't think there is any functionality in duplicating the Setup, Modules, Access, User/Profile menus. I think the ability to bring up the page tree exactly the way it looks with the "Pagetree sidebar navigation" would be much more useful.

Just some explanation because it is interesting... This isn't something that is specific to Repeaters - it applies to any selector used on a PageArray/WireArray (a Repeater field returns a PageArray). When you do $some_pagearray->find() this is different to a $pages->find() - the method name is the same but they are actually totally different methods. See find() method in the PageFinder class vs the WireArray class. When using $pages->find() the method refers back to the fieldtype for each queried field and the fieldtypes can do some special preparation to the queried value. In the case of a Datetime field the value is passed through strtotime() if it is a string. So this allows "today" to be converted to a timestamp. But when using $some_pagearray->find() this process does not happen, so the queried value must be a timestamp. Another gotcha to watch out for is using the page status as a string in a selector. With $pages->find() you can do something like "status!=hidden" but this won't work with a selector in $some_pagearray->find(). I think it would be nice if things like this did work with PageArrays - there is an open request for it.

The methods for setting new options for an Options field via the API seem to be a bit convoluted - I think it's probably an oversight and it would be worth raising a feature request at GitHub. There's a method that seems to be primarily intended for the admin back-end: setOptionsString(). You can use it but the way the options are defined (string with line break separator) is a bit weird for API use and it's not easy to get it to play nicely with existing options. $f = $fields->my_options_field; $manager = new SelectableOptionManager(); $options = 'red green blue'; // you can also set IDs and values if needed $manager->setOptionsString($f, $options, false); // if last argument is omitted/true you will remove any existing options Otherwise you could manually create SelectableOption objects, add them to a SelectableOptionArray, and use addOptions(), deleteOptions(), setOptions(), etc, with that SelectableOptionArray. See the module source code. It's hardly a simple process though. I think what's needed are methods to go from options to PHP array and PHP array to options.

I just copied the parts I used to one piece. You could also use different GET variables, but keep in mind to unset these again after rendering a single pagination. public function pageStart($limit){ $limit = (int) $limit; if(wire('input')->pageNum === 1 || $limit < 1){ return 0; } return (wire('input')->pageNum - 1) * $limit; } $pa = $pages->find("…, limit=15, start=".(!$input->get->second ? pageStart(15) : 0); $pa2 = $pages->find("…, limit=15, start=".($input->get->second ? pageStart(15) : 0); $pagination = $pa->renderPager(); $input->whitelist("second", 1); $pagination2 = $pa2->renderPager();

You can render two independent paginations, but only use one at a time. You'd use the getVars option or $input->whitelist() (if you need some filter values to be populated as well) to add a kinda "switch" GET variable, which tells you which pagination is currently used. When you know which pagination was clicked you can manually set the "start=" part to only the selector of the clicked pagination. There's no automated way to differenciate multiple paginations.

You could also add a custom api variable like that. $this->wire('variableName', $obj); In your case it's both config, but if you're adding something different this might even be more appropriate.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.