aaylasecura
Forum Replies Created
-
Thanks for looking into this. That’s the plugin I was installing via the built-in manual plugin upload of WordPress. I’ve never explicitly placed it into uploads, it looks like that’s what WordPress may do with it’s “Upload a plugin” for installation feature. It probably temporarily places it there before extracting and deleting it.
The uploads directory is 755 and
class-updraft-smush-manager.php
is 644 (which is ok, because it’s a file and doesn’t need the execute bit). I’m wondering why the error seems to imply that the uploads directory was attempted to be unlinked. Looks like in the functionunscheduled_original_file_deletion
theoriginal-file
meta field was blank and so$the_original_file
became just the base uploads directory.Thanks for replying. I’m just using the built-in WordPress upload plugin feature in Add new plugin, upload plugin. Then Query Monitor shows the below warning. Just noticed, the warning is due to trying to unlink the whole directory, actually, kinda strange:
unlink(/home/customer/www/staging28.dev.meditateinwellington.org/public_html/wp-content/uploads/): Is a directory
wp-content/plugins/wp-optimize/includes/class-updraft-smush-manager.php:1650
- This reply was modified 1 month, 1 week ago by aaylasecura. Reason: Added text content of warning
- This reply was modified 1 month, 1 week ago by aaylasecura.
Thank you and the team!
Hi and thanks for replying. I did apply the patch and it did not fix the issue for me. I even wiped my test installation and started clean, installed the plugin, applied the patch, verified the file change. It’s still showing those same warnings.
Forum: Plugins
In reply to: [Core Framework] Triggers dirty state on every time Gutenberg is openedI just saw this other support thread: WordPress Editor Conflicts | www.remarpro.com You can see this issue occurring in the video by the thread starter
Forum: Plugins
In reply to: [Core Framework] Triggers dirty state on every time Gutenberg is openedHi there, has this been investigated further? It is still happening. I have a new clean test install of WordPress 6.6.2 with no other plugins active, no content. Using the default Twenty Twenty Four theme. Every time I open the Site Editor (/wp-admin/site-editor.php) it comes up with multiple (6 to be specific) unsaved changes. I save, refresh and it shows up again, endlessly. It happens on other editor pages too.
Sorry, I tried to use the support chat on the website but the AI agent didn’t seem to understand my problem.
Thank you for the reply! Do you have any estimated release date for the membership plugin?
Just to add, perhaps the misunderstanding is coming from the fact that if I detach ALL the instances of the synced on the page, then indeed they do get different IDs. But my issue comes from wanting to have a synced pattern on the page and have a detached copy of it that is then modified on the same page. Not sure if this is just a shortcoming of WordPress that the IDs seem to always be linked.
Hi there, sure, I just made a video: https://youtu.be/YocM393DVEE
Forum: Plugins
In reply to: [Core Framework] Any way to inject our own classes programatically?Hi and thank you for replying. I’m developing a plugin for adding custom CSS based on user interactions and other triggers, and I would like to integrate this with CoreFramework and its search and auto-completion of classes inside a block editor.
For example, one of the things that my plugin (when CoreFramework integration is enabled in settings) will do, is get the list of classes from
CoreFramework\Helper
and for each one create a “responsive variation” in the form of, e.g.on-max-tablet--<class>
so that if this class name (or corresponding data attribute) is applied to the element, the<class>
will be added to the element when the device width hits a “tablet” breakpoint. And many similar interaction-triggers. I would like these, and other class names, that my plugin supports to be searchable and insertable via CoreFramework’s block editor integration (of course if the user enables this in settings).I’m sorry, I’m confused… I’m saying I did detach the pattern, and then duplicated it (the detached container), and it still didn’t generate a new ID. Am I misunderstanding you? Did you try my steps above and confirm that it generated a new ID for you?
Hi there and thank you for replying. However this is not what I’m seeing. I just tested this on a new clean WordPress install with just Greenshift, even with refreshing the page at each step:
- Create a new page
- Insert a Container block and set size and background color for it
- Save and refresh the page
- Save the container as a synced pattern
- Save and refresh the page
- Duplicate the synced patter or reinsert it again
- Detach the clone
- Save and refresh the page
- Duplicate the detached clone
- Save and refresh the page
- Change the background color for the detached clone
- Save and refresh the page
- The detached and later duplicated clone still has the same ID as the original synced pattern and its new background color applies to both blocks
There’s no way to force it to regenerate its ID once it’s been saved as a synced copy. This only happens if it has been saved as a synced copy; otherwise, as you say, it will regenerate its ID when it’s duplicated and page is refreshed and resaved
Thank you for replying, I’ve emailed the details above to the given address.
Thank you!