kongondo

Glad you got it sorted. I have just noticed that you are using a GET input in a selector without sanitizing it first. Here: $url_exhibition is not sanitized and you immediately use it here:

I struggle to read alternative PHP syntax but it seems to me you haven't defined $currentKey before the condition at line #55. If exhibition work title is not equal to the page title, you have no $currentKey, hence incrementing it at line 59 throws the error. Defining/initing it earlier, before line #55 ought to get rid of the error. E.g. $currentKey = 0; Not sure that your code will still work as intended though, so you'll need to test.

They are in the docs right here for text(): https://processwire.com/api/ref/sanitizer/text/ but you are right, it is not clear from the docs if these also apply to textarea().

Free access to Flutter Apprentice from October 6, 2021 through January 6, 2022. https://flutter.dev/apprentice-giveaway

I have learnt (sometimes the hard way) that mixing values or data types in the database for the sake of UI/UX is never a good a idea. Modelling a real world problem is many times not straightforward. Reading up on DB normalisation helped clarify things for me. Before I design any DB model / schema I ask myself two basic questions: Will users need to query the data? (e.g. searches, selector) Will the data require manipulations at the DB level? If the answer to any of these questions is YES, I throw out any notions of storing data as JSON. In 90+% of the time this will be the case. The data will need to be queryable. In fact, I rarely store anything as JSON (even with the not-so-recent MySQL JSON-capabilities - the pros and cons of which are a debate for another day, btw). The only thing I store as JSON are things like site settings, data points of a map for a chart, etc., as these don't need querying or direct computation applied on them. In this Fieldtype's case, I would steer away from JSON. The name of the field itself implies mathematical computation will be involved. I would use a DECIMAL data type to store the quantifiable values. You will then be faced with the age-old question of whether to expand horizontally (add more columns to accommodate more combinations of feet|inches- i.e. regular relational design) or expand vertically (add more rows - i.e., Entity Attribute Value [EAV]). Each of these have their pros and cons. Probably one way to do this is to try and ensure that you are comparing apples to apples at the DB-level. You can decide on a base unit that will be used to store all measurement values. For instance, centimetres. In the UI, the users will always see their measurements in the selected unit (feet, inches, etc). You can already see the problem with this ?. It requires knowledge of the type of measurement that is being stored, e.g. length, volume, area, etc! Does it mean you will have a base unit for all these groups of measurements? What about custom measurements that don't readily fit into one of these paradigms? I am probably overthinking this. Or I have been working on Padloper for too long ?. Good decision. I think it is 'easier' to bend the UI/UX to fit your DB model than the other way around. Sorry, I don't have much answers at the moment but hopefully this helps generate a meaningful discussion.

Thanks for this contribution @MarkE, Is there a reason you combine magnitudes into pipe-separated values? This makes it difficult to query. For example, what if I wanted to find values whose magnitude were > 10? Storing these pipe-separated strings make this tricky. I have only quickly looked at the code so you could have already figured this out. Combination units: I think I get the idea for this (e.g. the feet and inches). From an UX/UI point of view though, maybe it is prone to errors? Editors need to remember to input a pipe as well as remember what side of the pipe is what measurement. Maybe this is an exaggeration, as it is quite easy to remember feet|inches but what if it is another not-so-obvious combination? The auto-conversation feature looks cool though ?.

Windows here, works fine.

Hi Simon, Apologies for the late response. I haven't touched this since I built the prototype. I think the Page Builder conversation isn't finished yet. Some of the pending discussion IMO are: What type of Page Builder do people want? E.g. drag and drop with visuals, repeater-like-builder, etc. Technical aspects of the builder: e.g. coupling with existing ProcessWire fields or not, or both, etc. Community (seems more people prefer this(?)) -led versus commercial (other?) project/module. If community-led, who are the leads? Page Builder built on top of repeaters (seems many people would prefer this (?)) or separate module? Strictly Page Builder or a site builder as well? (maybe not as important a conversation to have). Are you building something yourself? Thoughts? Thanks.

That is probably not a valid ProcessWire page. ProcessWire does not output page URLs with .php extensions. A frontend page would be something like www.mysite.com/about-us/ or www.mysite.com/services/. In case you don't know which pages use which templates, find out if you have a template file called home.php and use that instead of basic-page.php. In that case, you would then have to visit www.mysite.com for the code to run. Yes, it's always good to make a backup of the database. In this case a backup of the files is not strictly necessary but it does no harm if you do. Let us know how it goes ?.

Hmmm. So this remains a mystery then.

I am wondering if this is happening only on multilingual sites (although I fail to see the connection why)? Is your site Multilingual? @AndZyk. Is your site multilingual? Mine is.

EDITED It should work for 'usual frontend' pages. Since non-super users will have view permission for such pages. The added layer of restriction with respect to repeaters wouldn't apply. Hope this makes sense. For instance, if you had a 'members' field that is only viewable to 'members', logged in members (non-superusers) will be able to see the field as long as that field was on a page that members have page view or edit access to. Meaning, if that page is not a child of an admin page (e.g. repeaters, etc), the permission set will kick in.

Maybe because of this? Repeaters are admin pages. Guests do not have view access to repeater pages (page where the field exists), hence, even though guest had view permission, they still couldn't view the field since it lives in a restricted area (repeater). In other words, their view permission was not 'applicable'.

Where is Schule and Meht Erfahren coming from? Is Schule coming from $page->title? Where is the content Musik erlerenen coming from? From $page->body? Or some other field? I am asking since there could be one or more permission restrictions in place. Possible issues: You have in condition in your template file that is restricting the output of the content. It could even be a hardcoded value of a page ID that doesn't existing in your import site. I.e., in the export site, SOME_PAGE might have the ID 1234 which when you import in your local/other site is saved as SOME_PAGE with ID 1255. You have a field-level view restriction. Especially if only the content of one field is not showing, I would focus on this. You have template-level view restriction. This means that SOME_PAGE utilises 'some-template' which has view restrictions. Is this happening on all the pages? Is it happening on pages that use different templates?

Hi @Allan, Welcome to ProcessWire and the forums. moderator note: I merged your two posts. I also added code blocks around your HTML code for better readability. In addition, I wrapped it inside a spoiler because it is a long piece of code. This also helps with readability (and scrolling).

Depending on what you are doing with the pages, you could do a $pages->findRaw($selector,$fields); instead.

99.9% of the time I use option #1 as detailed here, i.e. multiple sites with multiple databases AND ONE wire folder. Each site has its own database and /site/ directory (templates, modules, etc.). If I need a site (project) to be stand alone, I create the site separately with its own wire folder.

Thunder Client — lightweight alternative to Postman Thunder Client is a lightweight Rest API Client Extension for Visual Studio Code (it is not open-source). Launch article Quick demo

Yes. From your description, it sounds like you want you page to display differently depending on the view port (?) and/or device (?) it is being viewed on. In that case, you can accomplish that using CSS (apologies; I am not sure about your coding capabilities, so please, ignore me if you knew this already :-)) and JavaScript (most likely, optional). On the other hand, if what you actually meant is you want ProcessWire to output different gallery page views depending on some condition, then the answer is a tentative yes. We'd need to know what that condition is first. Maybe you could explain your use case? My feeling though is that you are referring to client-side conditions as opposed to server-side.

That's quite an old version of ProcessWire. ready.php and the likes were introduced in ProcessWire 2.6.7, so you cannot use ready.php in your version. You can still use the API to change your password. You will need to add the code to a template file. Pick one template file from your /site/templates folder, edit it, and add the following code. The steps are: Pick a template file. Open it for editing. Depending on your server, you might have to download it to edit it locally the upload the edited version. Add the code below. The code needs to be added within php code blocks within that template file. Do not delete your templates existing code. Visit a page on your website (frontend) that uses that template file (e.g. an about page that uses a template called basic-page, etc). Your password (and optionally user name) will be changed. Edit the template file in #1 and #2 above. Remove the password change code. Reupload the edited template file if it was edited locally. Go to your admin URL and login with your new password (and new name if you changed it as well). PHP code <?php namespace ProcessWire; #### DON'T ADD ABOVE TO YOUR TEMPLATE FILE. IT IS JUST FOR SYNTAX HIGHLIGHTING HERE #### ################# COPY CODE STARTS HERE ################# // get the default ProcessWire admin superuser $admin = $users->get(41); // turn output formatting off $admin->of(false); // change the password $admin->pass = "YOUR_VERY_STRONG_PASSWORD_HERE"; // change the user name (optional: comment out code if you know and want to use the existing user name) $admin->name = "YOUR_USER_NAME_HERE"; // SAVE YOUR CHANGES $admin->save(); ################# COPY CODE END HERE #################

Below is one way to detect if the page is new, in which case add our script. The disadvantage of this is that the whole file is only included under certain conditions as opposed to a just a function inside the file being called under certain conditions. This means the admin.js file will only be used for focusing the list_price field. There are other ways around this. Hopefully others will chime in with better solutions/ideas. Change the ready.php code I suggested above to this one: <?php namespace ProcessWire; $this->addHookBefore('ProcessPageEdit::buildForm', function (HookEvent $event) { $page = $event->object->getPage(); // new pages GET a 'new' query string/parameter, i.e. &new=1 // we check that $new = (int) $this->wire('input')->get('new'); if ($new && $page->template == 'book_sales') { $config = $this->wire->config; $url = $config->urls->templates; $config->scripts->add($url . "scripts/admin/admin.js"); } }); There's probably other more elegant ways to detect if a page is new but I cannot remember any of the top of my head at the moment.

OK. STEP #1 Create a file, e.g admin.js and save it to your preferred location. In this example, we have saved it at site/templates/scripts/admin/admin.js STEP #2 Add either of the below JS code in admin.js (you don't need both; choose one or the other). jQuery version: $(document).ready(function () { // #wrap_Inputfield_list_price is the ID ProcessWire will assign to your list_price field's wrapper (an li element). // you can confirm this by examining the markup around your 'list_price' input in dev tools. // Inputfields is a utility files that ships with ProcessWire. // more details: inputfields.js - JS specific to behavior of ProcessWire Inputfield forms. Inputfields.focus("#wrap_Inputfield_list_price") }) Plain JavaScript version: const InputfieldAdminScripts = { focusAnInputfield: function (inputfield_id) { const inputfieldToFocus = document.getElementById(inputfield_id) // if we found the element,focus it if (inputfieldToFocus) { inputfieldToFocus.focus() } }, } // DOM ready document.addEventListener("DOMContentLoaded", function () { InputfieldAdminScripts.focusAnInputfield("Inputfield_list_price") // this will also work here. you can use it instead of the above // Inputfields.focus("#wrap_Inputfield_list_price") }) STEP #3 Inside ready.php, add this code to load admin.js. You can modify this to only load under certain conditions if you wish. <?php namespace ProcessWire; $this->addHookBefore('AdminTheme::getExtraMarkup', function (HookEvent $event) { $config = $this->wire->config; $url = $config->urls->templates; $config->scripts->add($url . "scripts/admin/admin.js"); }); Please note that in Chrome (and maybe FF as well), if you have your dev tools opened and the cursor currently focused on it, the inputfield might not seem to be focused, but it actually is. ?

What field is this? Title field? There's two steps to this: Add your custom JS to the admin Add your code to the custom JS file. For #1, there's many different ways to do this. Have a look at these two threads, for instance: For #2, it depends on the input you want to target. The easiest way is to target it by ID. Or grab it using ProcessWire Inputfields API and focus it. If you can be a bit more specific about the field, we can provide ready-to-go code (some of which have been posted here already, actually).

No, you cannot focus an input using PHP. Autofocus is usually achieved using JavaScript. E.g. // get input you want to focus // in this case we know its ID, so we are grabbing it that way // we focus it using the focus() method // you could throw this into a function if you wanted document.getElementById("your_input_id").focus(); Alternatively, you can do this in the HTML, i.e. the PHP code that is outputting the HTML by using the autofocus attribute. <label for="my_input">Book Title:</label> <!-- the browser will focus this input when the page loads --> <input type="text" id="my_input" name="my_input" autofocus> <label for="my_input">First name:</label> <!-- the browser will focus this input when the page loads --> <input type="text" id="my_input" name="my_input" autofocus> References https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/autofocus https://www.w3schools.com/tags/att_input_autofocus.asp Read about the accessibility considerations if you will be using autofocus.

Here you have several options. Server-side, my favourite is WireCache ($cache variable). I am assuming you don't have ProCache. That would make your pages load even faster. You could also cache client-side on the browser.