Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/21/2019 in all areas

  1. This module enables you to send push notifications and receive information about sent notifications on your HTTPS ProcessWire website. It enables you to: Create a field of type FieldtypePushAlert that you can add to a page template. This is a multi-input field widget that enables you to send notifications from your page in the admin Page Edit and monitor statistics - Attempted, Delivered, Clicked, etc Send notifications from a page template directly using the API, eg to PW users who have a specific role and have subscribed to notifications Capture subscriptions on your website front end All kudos to the great support team at PushAlert and to all the ProcessWire developers who've helped me with this project. Download from the Modules directory at: https://modules.processwire.com/modules/push-alert/ or from GitHub at: https://github.com/clipmagic/PushAlert Full instructions for use are in the module README.md file. Enjoy!
    12 points
  2. I think this one of the most massive discussion about the project architecture I have ever read, featuring so many respected forum members, should not be left unanswered by the project lead. So feel like we need to bring it back up and ask @ryan to participate.
    5 points
  3. To have configuration fields for your fieldtype (displayed on the config tab) you'll need to implement ___getConfigInputfields(Field $field) in your Fieldtype class. To specify allowed overwrites you'll need to implement ___getConfigAllowContext($field) in your Inputfield class. As examples you may look at wire/modules/Fieldtype/FieldtypeTextarea.module and wire/modules/Inputfield/InputfieldTextarea.module. Edit: Please note that FieldtypeTextarea.module actually pulls additional configuration field from the InputfieldTextarea, so this is not a simple example for creating the config inputfields. A more straight forward example for ___getConfigInputfields would be wire/modules/Fieldtype/FieldtypeText.module.
    2 points
  4. @flydev Thanks a lot for your code! I implemented your switcher CSS and tried to add transition to get a smooth state change. Looks great and and fits seamlessly into the UI. The checkbox label is also positioned correctly. The transition I added doesn't work as smooth as expected. It's a bit clumsy... It would also be nice if the toggle switch would be based on rem/em - not px. Size scaling would be much easier. Here is the updated pen with the actual HTML: https://codepen.io/gadgetto/pen/omRwXW
    2 points
  5. ? this would be really nice. I also used to put stuff in the homepage, but this can get cluttered really easy.
    2 points
  6. I find that the need to set the value of one field to another field is so rare in practice that it cannot possibly outweigh the time, frustration and possible security flaws that dealing with turning off and on output formatting has caused me over the years. It is not hard to use $page->getUnformatted('field') in the rare instance when that is what I actually want to do. At least if I am unintentionally saving formatted values to other fields, it is just a mistake and not a potential security concern like outputting fields to the page that are not entity encoded is. And it certainly doesn't seem like it should be an application-terminating error. One example I recently ran into was calling a function to send an email while in the midst of editing a page via the api. In such a case you need to remember to turn off output formatting and back on again before calling the email function (and then back off again before doing your save), or your email will be outputting unformatted fields. it took me ages to figure out why the dates in my emails were sometimes coming out as timestamps. I use setAndSave() now wherever I can, but I do wish I could use the regular object setting syntax sometimes. I think this is why people say that "global mutable state" is dangerous.
    2 points
  7. First off, just increase raw power. Try bumping up your VPS with more power. Easy solution and this stuff is so cheap nowadays. Upgrade the software if possible I've had instances with 300+ fields on a template with more than 500k pages. Queries started to slow down around 200 fields. I bumped the Mariadb version to the latest, switched to INNOdb, PHP 7.2.x and it was running pretty smoother on a digitalocean medium sized VPS ($40/mo). We also had tons of runtime fields and we cached those so a page save would do the calculations instead of calculating runtime. When we eliminated those the application became really snappy with 200-300 concurrent key users doing all kinds of imports and running reports while the 1000 regular concurrent users didn't notice lots of slowdown. Most of the slowdown nowadays come from the interface itself. We used a lot of jQuery kinda tooling inside ProcessWire admin and since the users don't have the fanciest computers, some browsers are not really capable of rendering the back-end. I guess we needed to switch to a SPA, but I'm not working on the project anymore. Jup, this is the key. Especially while desiging applications this is really important. Try to split up as many as you can. I don't store address information on the order, but on the client, and possible even on an address template which you can re-use. You can also use Page fields to combine all those. To comply to GDPR you can also store the blob of address info in one or two fields on the order itself. So if a client requests to remove his data you can easily remove the accoun and associated addresses. And you still have the address data. Another solution is to use the FieldsetPage to create on instance of all address/personal information. In the background PW creates another page containing the info. You add this field to the page once for invoice and once for the shipping info.
    2 points
  8. OK, I found a solution for my topic. I copy just all $session values to a bypass array, clean up this array from user related data "_user" and push my stored values back to the new session. I think only the $session key "_user" contains sensible data? In sum, user is after logout "guest" again, but my $session vars got not lost... # COPY SESSION VARS $session_bypass = $session->getAll(); # LOGOUT USER / RESET SESSION if ($user->isLoggedin()) { $session->logout(); } # REMOVE USER DATA FROM SESSION COPY > DELETE KEY "_user" if (array_key_exists ("_user", $session_bypass)) { unset ($session_bypass["_user"]); } # RESTORE SESSION WITHOUT "_user" KEY foreach ($session_bypass as $key => $value) { $session->set($key, $value); }
    2 points
  9. A module helping you to manage SEO related tasks like a boss! Automatically generates and maintains a XML sitemap from your pages. Includes a Fieldtype and Inputfield to manage sitemap settings and meta data for pages (Title, Description, Canonical URL, Opengraph, Twitter, Structured Data etc.) Multi language support for the sitemap and meta data. Configure default values for meta data on template level and let pages inherit or overwrite them individually. Map existing fields to meta data, reducing the need to duplicate content. Live preview for content editors how the entered meta data appears on Google. Live preview for content editors how the entered Opengraph data looks like when sharing a page with Facebook. Check out the README on GitHub for more details, including usage instructions. The module is currently released as beta and needs testing! Please report any issues on GitHub or in this forum thread, if you find time to give it a try ? Examples Here is an example of rendered meta data you will get from a single SeoMaestro field: <title>Sed dictum eros quis massa semper rutrum. | acme.com</title> <meta name="description" content="Si lobortis singularis genitus ibidem saluto. Dolore ad nunc, mos accumsan paratus duis suscipit luptatum facilisis macto uxor iaceo quadrum. Demoveo, appellatio elit neque ad commodo ea. Wisi, iaceo, tincidunt at commoveo rusticus et, ludus."> <meta name="keywords" content="Foo,Bar"> <link rel="canonical" href="https://acme.com/en/about/"> <meta property="og:title" content="Sed dictum eros quis massa semper rutrum."> <meta property="og:description" content="Si lobortis singularis genitus ibidem saluto. Dolore ad nunc, mos accumsan paratus duis suscipit luptatum facilisis macto uxor iaceo quadrum. Demoveo, appellatio elit neque ad commodo ea. Wisi, iaceo, tincidunt at commoveo rusticus et, ludus."> <meta property="og:image" content="https://acme.com/site/assets/files/1001/og-image.jpg"> <meta property="og:image:type" content="image/jpg"> <meta property="og:image:width" content="1600"> <meta property="og:image:height" content="1200"> <meta property="og:image:alt" content="Lorem Ipsum"> <meta property="og:type" content="website"> <meta property="og:url" content="https://acme.com/en/about/"> <meta property="og:locale" content="en_EN"> <meta name="twitter:card" content="summary"> <meta name="twitter:creator" content="@schtifu"> <meta name="twitter:site" content="@schtifu"> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "About", "item": "https://acme.com/en/about/" } ] } </script> <meta name="generator" content="ProcessWire"> <link rel="alternate" href="https://acme.com/en/about/" hreflang="en"> <link rel="alternate" href="https://acme.com/en/about/" hreflang="x-default"> <link rel="alternate" href="https://acme.com/de/ueber/" hreflang="de"> <link rel="alternate" href="https://acme.com/fi/tietoja/" hreflang="fi"> And some screenshots of the UI:
    1 point
  10. WireCache is a really nice way to quickly cache data to the database, but when working with json data there are some quirks. Imagine the following examples: $data = $cache->get('my-key', WireCache::expireHourly); if(!$data){ $data = […] $cache->save('my-key', $data, WireCache::expireHourly); } // API response $response = json_decode($data); $image = $response->data[0]->image; // or $html = "<div data-json='$data'></div>"; Both should work from the quick look. Both will fail as soon as the cache kicks in. This is because the implementation of WireCache tries to be smart and does automatically decode data, which is detected to be json. But it doesn't just decode it like in my example, but rather uses json_decode()'s second parameter to decode the json as associative array(s) instead of stdobject(s). If you prefer the object syntay to traverse your json data or you really want to store raw json, then I've got two hooks for you, which do prevent the automatic json detection of WireCache, so you can work with the stringified json as you need to. Just replace the get() and save() calls in the example with getRaw() and saveRaw(). $wire->addHook('WireCache::saveRaw', function(HookEvent $event){ $args = $event->arguments(); $args[1] = '::RAW::' . $args[1]; return $event->return = call_user_func_array([$event->object, 'save'], $args); }); $wire->addHook('WireCache::getRaw', function(HookEvent $event){ $args = $event->arguments(); return $event->return = str_replace('::RAW::', '', call_user_func_array([$event->object, 'get'], $args)); });
    1 point
  11. Creating a support topic for this action now that the new actions-as-modules feature has been added to Admin Actions. Unordered List to Pages An action for the Admin Actions module for ProcessWire CMS/CMF. Creates a structure of new pages from an unordered list entered into a CKEditor field. The nesting of further unordered lists within the list will determine the nesting of the created pages. Created pages get a default template that you select, and you can override this default template per list item by specifying a template name between [[ ]] delimiters. This action can be useful to quickly create a page structure; especially so if you are rebuilding an existing non-ProcessWire site that has a Sitemap page that you can copy and paste from. Usage Install the Unordered List to Pages module. Visit the Admin Actions config screen and enable the "Unordered List to Pages" action for the roles who are allowed to use it. Navigate to Admin Actions > Unordered List to Pages and fill out the config fields: Source Enter/paste an unordered list in the Source field. There is a "cheatsheet" field above that explains the syntax you can use to set some template options for each list item. If you want to override the default template for an item you can specify a template name after the page title between double square brackets. If the template doesn't already exist it will be created. Example: Page title [[staff_members]] You can also specify one or more allowed child templates for a template like so: [[staff_members > manager tech_support]]This would create the page using the staff_members template, and set the allowed child templates of staff_members to manager and tech_support. Alternatively you can specify one or more allowed parent templates for a template like so: [[manager < staff_members]] This would create the page using the manager template, and set the allowed parent templates of manager to staff_members. Parent page Select a parent page that the new pages will be created under. Default template Select the default template to use for the new pages. Screenshots Action config: Result: https://github.com/Toutouwai/AdminActionsUnorderedListToPages https://modules.processwire.com/modules/admin-actions-unordered-list-to-pages/
    1 point
  12. Hello for all, ConfigurationForm fieldtype module is one my experiment from 2016. Main target to build this module was to store multiple setup and configuration values in just 1 field and avoid to use 1 db table to store just single "number of items on page", or another db table to store "layout type" etc. Thanks to JSON formatted storage this module can help you to reduce number of PW native fields in project, save DB space, and reduce number of queries at front-end. Install and setup: Download (at the bottom ), unzip and install like any other PW module (site/modules/...). Create some filed using this type of field (ConfigurationForm Fieldtype) Go to field setup Input tab and drag some subfields to container area (demo). Set "Name" and other params for subfields Save and place field to templates ("Action tab") How to use it: In my case, I use it to store setup and configurations values, but also for contact details, small content blocks... (eg. "widgets"). Basic usage example: ConfigForm fieldtype "setup" has subfields: "limit", type select, option values: 5, 10, 15, 20 "sort", type select, option values: "-date", "date", "-sort", "sort" // get page children (items) $limit = isset($page->setup->limit) ? $page->setup->limit : 10; $sort = isset($page->setup->sort) ? $page->setup->sort : '-sort'; $items = $page->children("limit=$limit, sort=$sort"); Screenshots: Notes: Provide option to search inside subfields Provide multilanguage inputs for text and textarea field types Provide option for different field layout per-template basis Do not place/use field type "Button" or "File input" because it won't works. Please read README file for more details and examples Module use JSON format to store values. Text and textarea field types are multilanguage compatible, but please note that main target for this module was to store setup values and small content blocks and save DB space. Search part inside JSON is still a relatively new in MySQL (>=5.77) and that's on you how and for what to use this module. Thanks: Initial point for this fieldtype was jQuery plugin FormBuiled and thanks to Kevin Chappel for this plugin. In field type "link" I use javascript part from @marcostoll module and thanks to him for that part. Download: FieldtypeConfigForm.zip Edit: 14. August 2018. please delete/uninstall previously downloaded zip Regards.
    1 point
  13. A simple module to enable easy navigation between the public and the admin side of the site. After installation a green bar will appear to the upper side of the screen, containing a few navigation elements and displaying the PW version number. Heavily inspired by @apeisa's great AdminBar (Thanks!). I needed a bit simpler tool for my projects and as a result, this was made. Available on GitHub .
    1 point
  14. Thanx for the help! Module refresh did not help but saving settings did.
    1 point
  15. Hey @szabesz - a modules refresh and/or Tracy settings save will fix that. I converted one of the settings from a string to an array. I probably should have handled it better, but that's all you need to do.
    1 point
  16. Good day, @Robin S! Starting a new site. Creating structure with this module is really a breeze! Thanks! I have spotted a minor inconvenience when preparing a list in a test editor and pasting it into the Source inputfield. The text editor (or is the inputfield itself?) is adding <p> tags around the <li> contents. And this leads to creating 0 pages. Would be awesome to clear all markup but the ul>li before processing.
    1 point
  17. Thanks @OLSA for this reply. This put me back on some tests I had done previously but didn't work, but I've managed thanks to you ! ? In fact, I had tested the hook you mentionned (for the 1st time, by reading about it in the 'Custom PHP cide' section in the template page) but I had put it in a _init.php file I include in all my templates, but I guess this was the wrong place for back-end templates. From what you've indicated, I put my code in admin.php and it works as expected ? So a big thanks to you ! For information in case someone reads this, here's my code : $wire->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $e) { $user = wire('user'); $pages = wire('pages'); if($e->object->name == 'group') { if ($user->isSuperuser()) { $selector = "template=group, sort=title"; } else { $selector = "template=group, created_users_id=$user->id, sort=title"; } $e->return = $e->pages->find($selector); } }); Of course, I had to remove my selector string in the template page because it triggered an error otherwise by indicating that the saved page didn't match.
    1 point
  18. Create two templates: "addresses" and "address". Put in a checkbox called "primary" and attach other fields (i.e. FieldtypeStreetAddress). Create a pagefield on the user template called "addresses". Now you can have as many addresses as you want, but when the user loads it won't instantly loads all the address field. Just the page field with the ID's. If you need to render it on the front-end with the primary first, you can easily sort or assign another class to highlight the primary address. Since the Page field is really powerful and we use a relational database, try to use it as much as you can. Be careful with too many joins, but for this use case it would suffice.
    1 point
  19. Or use the option manager with a fixed string, something like this: $field->save(); // save field first $manager = new \ProcessWire\SelectableOptionManager(); $manager->setOptionsString($field, __("Yes\nNo"), true); $field->save();
    1 point
  20. @flydev's solution should do the trick for you, nice and clean, unlike the uikit one that had to negotiate the specificity issues inherent with uikit. If not I am happy to take a look for you.
    1 point
  21. You can try to get that using hook below. But please note, because you want to get that works only inside back-end (admin) place this in site/templates/admin.php before require(...) statement: // site/templates/admin.php // set different SelectablePages for page field "group" in case if user is superuser wire()->addHookAfter('InputfieldPage::getSelectablePages', function(HookEvent $e){ // here we check desired page field only if($e->object->name == 'group'){ if( wire('user')->isSuperuser() ){ $e->return = wire('pages')->find('template=group, sort=title'); } } }); Thanks to PW there are and other options to get the same (eg. hook in custom module, or ready.php). Regards.
    1 point
  22. Hi @eelkenet Thanks for your feedback, glad you are liking the module! I see your point. Content editors are currently limited to edit meta data on page level. However, I doubt that the home page would be the desired place to to so: Setting default values on field level allows to leverage different data per template. You can edit the field in the context of any template and change the default meta data, you can even change what groups/fields are displayed to the editor per template. If we place this on the home page, we are mixing configuration and content + we would need to build another UI around that. I think the correct place to edit the default values would be a dedicated page in the admin (e.g. under "Setup"), with a new permission (e.g. "seomaestro-edit-config") that you could give to your content editors. I am not 100% sure what you mean by "follow the same inheritance structure as pages do". Does this mean that any page should inherit meta data of the parent page, unless overridden? I do not think that this works well for meta data, because the goal is to have unique meta data (no duplicate titles or descriptions). This data must be defined on the current page, or mapped from a field of the current page. This should work already ? Just enter {title} | {parent.title} and save the page. Cheers
    1 point
  23. Yeah, I kinda agree with you - it's a bit annoying at times - I have gotten used to the keyboard shortcuts to increase/decrease as needed. Not sure how easy it would be to do what you want because I make use of the splitjs library (https://github.com/nathancahill/split) for that stuff and it's a percentage based setup and not sure how I would go about overriding that at the moment - it's certainly on my mind though.
    1 point
  24. Cool, will update. Something unrelated I'll just throw out there for the wishlist... it would be cool if the code window in the Console didn't resize proportionally when the panel is resized. So the code window would have a pixel height rather than a percentage height and the result window would have a height along the lines calc(100% - [console window pixel height]). I know you added a lot of neat stuff relating to the code window height (line snapping and keyboard shortcuts) and for all I know this request would complicate all of that, in which case don't worry because it's not that important. ?
    1 point
  25. Thanks, working well for me as guest/non-superuser on localhost, and when using User Switcher on remote host.
    1 point
  26. And I think the key thing is that on a remote server you can still use the user switcher to change to a non-superuser and it will work - it's just that I don't want actual non-superuser users that might have the tracy-debugger permission from using it. I think that last version I just committed should be ok for this scenario. I am double checking here now, but could you confirm at your end also please?
    1 point
  27. Okay with me as I do almost all development on localhost.
    1 point
  28. Hey @Robin S - sorry about - I went through a few different iterations of things and looks like I messed up a couple of things on the last version. I just made a quick fix (no version bump) that fixes it for local guest users, but I think I need to do a bit more to get non-superusers working. Feel free to test the recent commit, but hopefully will have a complete fix shortly.
    1 point
  29. Thanks for adding this feature! There seems to be a problem with the console output though. No matter what I dump the output consists of the entire rendered page. This occurs when using the console as guest or logged-in non-superuser.
    1 point
  30. @bernhard, thanks for the pull request. I've merged parts of that along with a few more of my own changes. But probably not necessary to do much more with this particular repo though because it really only exists to serve as a quick demo for people like yourself who might like to take the idea further. I'm not feeling possessive of this idea/code at all so anyone is very welcome to take it and use it for their own purposes in any way they like - further developments don't need to happen via my repo. To go further into something that would be more widely useful to the community, shared in the modules directory, etc, would require a new module that doesn't bundle any particular Process module like my demo does. I'm imagining something that would work with any custom Process module. And maybe focuses on the iframe approach because that seems the most promising (I was also playing around last night with the same JS library you mentioned). I might tinker around with something later but anyone is welcome to have at it and beat me to it. ? To respond to some of your points... Great, we don't want that exposed. I wish there was a better way than string replacement on the whole HTML output but there isn't any way I can see to set that part of the JS config object directly and I fear setting $config->urls->admin before the page render could have other unwanted consequences. The redirect isn't really about the ?modal=1 (although that is unwanted) - it's the Post/Redirect/Get pattern. If you look at the core Process modules you'll see that they all redirect after form POST submissions. In any case the specific code within the demo Process module is not something that anyone needs to use, it's just so the demo module renders something visible. What a person puts in their execute methods will depend on what they want their module to do. Incidentally, setting $this->wire('input')->get->modal = 0 unfortunately doesn't solve the problem for redirects as these still have the modal parameter forced onto them. I think the simplest solution for that is just to make sure any redirect URLs include "//" (e.g. use http URLs). I think it is too late within any Process module to throw a 404 exception. The best I could come up with is to check that any URL segment is valid and if not redirect to the 404 page. Maybe someone will discover a better way. Thanks to this post I think I have a solution for this, added in the recent commit. ProCache can run on any page where the user isn't logged in, which for guests will be all pages besides the ones executing a front-end Process module.
    1 point
  31. @Steve_Stifler, if you are thinking database-wise, this probably needs some refinement. The database behind PW indeed has a table "Pages" which holds vital information about a particular page, which includes its unique identifier, the identifier of its parent page, the assigned template and a name, to name a few, but no real data. It primarily defines the pages location within the page tree. Data, in contrast, is stored in individual tables which directly relate to a particular field. One row of such a field table contains "the value" (like a string, integer etc.) and the id of the page, to which this particular row belongs to. For this reason a particular field can only exist once on a page (you may, of course, have multiple fields using the same fieldtype assigned to the same page). So, if a page hosts 10 fields, then accessing the data of these 10 fields requires access to 10 tables of the database (which is cached in PW, so you do not need to bother with that). On the other hand, with PW it is rather simple to create own fieldtypes which refer to multiple database columns. So, if your standard row of data consists of 10 values, you may create an inputfield holding exactly these 10 values, which are stored in a single row of a single table. As long as you can define your data from the existing inputfield types, creating own fieldtypes is really a no-brainer.
    1 point
  32. That's not really true. The number of fields and templates does matter as those will be autoloaded for every request hitting processwire. It's not like 10 fields make a difference, but adding an additional 100 fields or 100 templates can indeed cause a slow down. It's different with pages though. Those are really only loaded on demand.
    1 point
  33. Hi @Wanze, congrats on your nice module! I'm currently testing it out for a client and find it overall very nice, thank you for your work! I have some feedback, even though I'm not sure if I'm understanding everything you do correctly. So please excuse me if I'm mistaken ? Having to set the default values for the meta tags on the field/template level, instead of using the PageTree (the Page level) seems unpractical. Most of the time I give a site editor access to the PageTree, sometimes to some modules, but I definitely keep them away from 'dangerous' stuff like Fields and Templates. However, editors should always be able to edit the SEO information without bugging the developer for an update. In other words, the preferred place for the default SEO information should imho be at the root of the tree: the homepage. (Or perhaps inside the a module config). To me it would make total sense that SEO information follows the same inheritance structure as pages do. Often rendered titles will consist of a page title and some ancestor title. So you should be able to select the parent's title and expand on it, much like the 'List of fields to display in the admin Page List') -home (title: "My Site") |-projects (title: "Projects") ||-project1 (title: "Project number 1") ||-project2 (title: "Another project") It would make sense to be able to get the following: -home (seo.meta.title: {title} would result in "My Site") |-projects (seo.meta.title: {title} - {parent.title} would result in "Projects - My Site") ||-project1 (seo.meta.title: {title} - {parent.parent.title} would result in "Project number 1 - My Site") ||-project2 (seo.meta.title: {title} | {parent.title} | {parent.parent.title} would result in "Another project | Projects | My Site")
    1 point
  34. Hi Jeremy and welcome to the forum ? I know that feeling, coming from a terrible one ? Sounds like a lot of work ? And I know what I'm talking about: ProcessWire is great for building custom forms for whatever "datatype" you need (regular page edits) and for building relations between those pages. It is IMHO not so great for displaying this data in a user-friendly way. We have listers and we have MarkupAdminDataTable, but both are not ideal for a little more complex tabular data (and I guess that's what you'll need a lot for such a system). That's why I built RockFinder, RockGrid and recently also RockCharts (early stage, not released yet). All of them are not totally easy to use for non-devs. You'll also need to learn how to create custom admin pages, but that's easy ? And finally, you'll need to grasp the concept of hooks: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks To make everything maintainable (and maybe also reusable), you'll need to pack everything in a module: https://processwire.com/docs/modules/ Good luck and have fun ?
    1 point
  35. This looks really promising! What do you think? I'm using this library: https://github.com/davidjbradshaw/iframe-resizer It's as simple as adding your iframe to your frontend: <style>iframe{width: 1px;min-width: 100%;}</style> <iframe id="myIframe" src="/your-public-backend-page/" scrolling="no"></iframe> <script>iFrameResize({ log:true, bodyMargin: '0 0 30px 0', }, '#myIframe')</script> Further improvements could be to sync the page url with the iframe url, but the great thing is: We'd only have to do this once and could use it on all our projects. No matter what frontend we are using! Imagine what a powerful tool this could be: Creating forms, registration pages, carts, event signup pages etc etc., everything as modular and reusable as we know it from the pw backend. And everything instantly styleable via RockSkinUikit ?
    1 point
  36. Thx Robin, this is (almost) awesome! ? I forked your repo and did two minor changes: I implemented a hookable method to modify the HTML, here to remove the admin url that is exposed in the pw config js object: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/1fed071d3f951b82fbae6c98b2c4834efec2b6bd I removed the $session->redirect in the processmodule. I guess the reason why you did that was to get rid of the ?modal=1 parameter in the url? The parameter is appended in InputfieldForm when ?modal=1, so I reset this parameter on initialisation of the process: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/d19f71c03b7169734dca243bc45f35a205782bf3 Do you know how/if we could throw a regular 404 on a Unrecognized path exception in the backend? Thank you very much for your work on this! ?
    1 point
  37. Version 0.5.0 fixes two issues, please update: Fix wrong url in the <link rel="alternate" hreflang="x-default"> meta tag. Fix date formatting for the lastmod property in the XML sitemap. Cheers
    1 point
  38. With the the relatively new ProField FieldtypeFieldsetGroup it should be a quick job to add this to all templates.
    1 point
  39. @csaeum Are you sure that the name of your Seo Maestro field is "seo"? Did you create the field? Looks like the $page is not aware of it. Cheers
    1 point
  40. Thanks @B3ta I think that the decision where the Seo Maestro field is rendered should be left to the user. And it should be done in the same way it works for all fields: By editing the template and placing the field. Display it in a new tab? Create an InputfieldFieldsetOpen and wrap the field. But maybe the content editor only needs to see meta title and description - then it's not worth to create a new tab. I understand that it requires some manual work to add the field to all templates, but I don't think it is the responsibility of the module to do this. There are other solutions like the Migrations module, which can do this task in a few milliseconds. For the project I built this module, it took me 10 minutes to write a migration that creates and configures the field, adds it to all templates, tweaks the settings per template and also wraps it in a tab. No need to do this by hand if I deploy to production. Cheers
    1 point
  41. Same feelings also. I think Teppo really said well how I felt also when read the latest post (and discussion about api examples). That kind of optimization is nice per project, but it is really confusing for a platform that we use to maintain and build hundreds of websites and applications with multiple developers. I'm all in for introducing breaking changes for 4.0. That would get rid of compiler also.
    1 point
  42. I've put in a feature request for this on GitHub: https://github.com/processwire/processwire-requests/issues/207
    1 point
  43. I'm having the same issue. It appears that this happens because Repeater fields add new items using AJAX, and InputfieldAceExtended loads its scripts with $config->scripts in render() method. But it doesnt work as PW does not consider rendering the scripts in $config->scripts when loading an input with AJAX. Quick solution is to append <script> and <link> or <style> tags after inputfield markup. From a quick search, native and profields don't seem to have this issue because they use the scripts that are loaded on backend by default. I think solution is up to @ryan at this point. When rendering the field PW should output scripts & styles too. // InputfieldWrapper.php public function ___renderInputfield(Inputfield $inputfield, $renderValueMode = false) { // ... if($ajaxInputfield) { $inputfieldID = $inputfield->attr('id'); if($ajaxID && $ajaxID == $inputfieldID) { // render ajax inputfield $editable = $inputfield->editable(); if($renderValueMode || !$editable) { echo $inputfield->renderValue(); } else { echo $inputfield->render(); echo "<input type='hidden' name='processInputfieldAjax[]' value='$inputfieldID' />"; // Get scripts from $this->config->scripts and output to browser } exit; //...
    1 point
  44. Actually i found the answer $num = count($Page->comments); "<p>Page has $num Comments</p>"
    1 point
×
×
  • Create New...