Leaderboard

Today's setup for multi-browser / OS testing. Chrome and IE11 on Windows and Safari on the Mac. (Beer not in the frame) ??

ProcessWire InputfieldRepeaterMatrixDuplicate Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time. This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module. Check out the screencast What the module can do Duplicate multible repeater items from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Configurable dialogs for copy and paste Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Attention, please note! Nested repeaters cannot be supported technically. Therefore a check is made to prevent this. However, a nested repeater can only be detected if the field name ends for example with "_repeater1234". For example, if your MatrixRepeater field is named like this: "content_repeater" or "content_repeater123", this field is identified as nested and the module does not load. In version 2.0.1 the identification has been changed so that a field ending with the name repeater is only detected as nested if at least a two-digit number sequence follows. But to avoid this problem completely, make sure that your repeater matrix field does NOT end with the name "repeater". Changelog 2.0.1 Bug fix: Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided 2.0.0 Feature: Copy multiple items at once! The fundament for copying multiple items was created by @Autofahrn - THX! Feature: Optionally you can disable the copy and/or paste dialog Bug fix: A fix suggestion when additional and normal repeater fields are present was contributed by @joshua - THX! 1.0.4 Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3 Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2 Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1 Bug fix: Various bug fixes and improvements in the duplication process 1.0.0 Initial release Support this module If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!) Download this module (Version 2.0.1) > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/ > Old stable version (1.0.4): https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate/releases/tag/1.0.4

I'd be keen to have an option to enable the Console for non-superusers on localhost. If it's limited to localhost then there's not really a security risk I think. It would be handy for checking things like $page->addable(), $page->publishable(), etc from the perspective of a non-superuser role. When testing I typically keep an incognito window open with an editor role logged in rather than work with the User Switcher.

I guess it's just CSS? a.InputfieldRepeaterAddLink.InputfieldRepeaterMatrixAddLink.InputfieldRepeaterAddLinkInit[data-type="3"] { font-size: 0; width: 150px; height: 100px; display: inline-block; background-image: url(https://via.placeholder.com/150); background-repeat: no-repeat; } span.ui-priority-secondary { display: none; }

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

This is an additional plugin for the CKE. You can download it below and simply configure it as an additional plugin in PW. ? https://ckeditor.com/cke4/addon/loremipsum

That explains the closing delimeter thang quite well. Thanks.

Version 0.4.0 renders some common meta tags not managed by the fieldtype, and fixes a couple of issues reported. Thanks! See https://github.com/wanze/SeoMaestro/releases/tag/v0.4.0 for more information. Cheers

I've put in a feature request for this on GitHub: https://github.com/processwire/processwire-requests/issues/207

My favourite books are "Thinking, Fast and Slow" and "Rework". I would strongly recomend them for those people who care about their business and team building. Luckily, they are not ones of those who try to proclaim their business in a hidden oe even open way; they are more practical.

You can also just call it /site/ if you prefer. We only use /site-default/ initially so that people can continue to keep it cloned easily via Github without worry of it overwriting anything in their /site/ dir. As a result, there is no /site/ dir on the GitHub source (instead it's /site-default/ solely for GitHub). This is correct. Also note that the installer moves /site/install/files/ to /site/assets/files/. So if you were creating a new profile, you would copy your /site/assets/files/ to /site/install/files/ before zipping up your /site/ dir into a new profile. Also correct. This is so that you can create a site, and then easily export it as a profile just by exporting the database. The installer requires a fairly simple SQL file since ProcessWire uses PHP's MySQL commands to create the DB and insert rows. so things like extended inserts and such probably won't work. So here is the command I use to create a dump for a new profile: mysqldump --complete-insert=TRUE --add-locks=FALSE --disable-keys=FALSE --extended-insert=FALSE --default-character-set=utf8 -u[user] -p[password] [db_name] > install.sql After that, I edit the dump file with a good utf8 compliant editor (I use BBEdit/Textwrangler), and remove any extra junk that MySQLdump adds at the top and bottom of the file. This means remove anything that is not a "CREATE TABLE" or "INSERT" statement, unless you specifically want it there. Then I find the part where the insert statements are for table "users" and I remove all users except guest (ID 1). Likewise, remove all the insert statements for table "users_roles" except for the first one, which assigns role "guest" to user "guest" (1,1,0). Then your install.sql is ready. You are correct on all of this. You basically just create the site you want the profile to be. However, you shouldn't need to manually delete any images from assets, as deleting them on the page (or deleting the pages you don't want) will handle deletion of them automatically. This is right, but you can exclude everything from assets other than the dir itself. Your /site/assets/files/ should be copied or moved to /site/install/files/ (as mentioned above) before creating your profile. Why do we do this? Well if you deliver the profile with /assets/files/ already in place, and the file permissions weren't retained for one reason or another (like when they FTPd them or something), then you'd have to tell the user how to make all of the files in /assets/files/ writable. If they don't have shell access, this could be a time consuming process... a lot harder then just making /site/assets/ writable. By making ProcessWire move them from /site/install/files/ to /site/assets/files/, it ensures that there can be no issue with messed up file permissions, since ProcessWire will have created the files. If for some reason, ProcessWire can't move them from /site/install/files/ (like if permissions were lost when the user uploaded the files), then ProcessWire will copy them instead. Either way, it'll be able to complete the install with minimum hassle to the user. For the time being, the install profile will include the entire database. But not having made a lot of different install profiles yet, I've not given a lot of thought to doing it differently. It is possible that the core tables will be created/installed separately in the future. If you want to make something future proof, perhaps I should go ahead and make that change now... moving the core table creation outside of the site profile. This won't be too difficult from this end, and I imagine I could have that chance in place within a week. If it helps, here is my profile creation shell script. It creates a profile from a site that is running, so it goes and moves things around temporarily, creates the zipped profile, then moves them back. You'll see several things that get renamed to a ".old" version. My zip command (and .gitignore file) excludes files ending with ".old", so they are basically removed from the picture temporarily. I run this script after I've already exported the database, and placed it in /site/install/install.sql, using the method mentioned above. #!/bin/bash cd /Users/ryan/htdocs/sky/ <-- sky is the root dir of my PW installation chmod -R og+rw ./site/assets/* rmdir ./site/assets/files/* <-- this removes blank directories mv ./site/assets/files/ ./site/install/files/ mv ./site/config.php ./site/config.php.old <-- take the live config.php file out of the picture temporarily mv ./site/config-original.php ./site/config.php <-- and use a config.php without DB settings in it mv ./site/assets/cache/ ./site/assets/cache.old/ mv ./site/assets/logs/ ./site/assets/logs.old/ mv ./site/assets/sessions/ ./site/assets/sessions.old/ mv ./site/assets/installed.php ./site/assets/installed.php.old zip -r -v ./site.zip ./site/* -x@zip_exclude.lst <-- create the zip file, excluding stuff mentioned in zip_exclude.lst mv ./site/install/files/ ./site/assets/files/ <-- now move everything back so our site will still work... mv ./site/config.php ./site/config-original.php mv ./site/config.php.old ./site/config.php mv ./site/assets/cache.old/ ./site/assets/cache/ mv ./site/assets/logs.old/ ./site/assets/logs/ mv ./site/assets/sessions.old/ ./site/assets/sessions/ mv ./site/assets/installed.php.old ./site/assets/installed.php And here is my zip_exclude.lst file, referenced in the "zip" command above. You may not need anything other than the "*.old" and *.old/*" in yours. But I'm running on a Mac and use VIM, so most of these clear up potential files related to those. .DS_Store *.DS_Store *.old *.old/* sess_* *.cache *.swp *.sh Thanks for using it! Ryan