Cidram: WordPress Updates

[100percentlunarboy]

Hi. I love the script but I find it difficult as a WordPress user to continue using it.

Specifically, the way the update system works from within WordPress. If you go to plugins, Installed plugins, and update CIDRAM from there it updates the plugin but it has some bad consequences: 1. Reverts your install to the default Admin login ID and Password (this is especially bad if someone enables auto-updates for CIDRAM in the WordPress plugins section). 2. Wipes out all the additional components setup (if you are using CIDRAM on 8 websites, for example, it's a lot of work to set this back up).

I used to get around this by going into the frontend and running updates from there. The plugin would then show as updated in the WordPress plugins section. Tried that today but after running updates, in the CIDRAM frontend, the plugin still showed as needing an update.

I feel bad even bring this up since you have been so cool working on this for so many years, but I think its a topic that should be discussed.

Do you have any plans to make CIDRAM more compatible with the WordPress plugin update system? I don't have an issue with any other plugins wiping out any customizations made when updating. I feel that the current way CIDRAM works in WordPress discourages a user from updating. It takes way too much time to update from within the frontend when you are using the script on multiple sites, and as I mentioned, that method no longer results as the plugin showing as updated in the WordPress plugin section. I always have the frontend disabled so I first login with FTP and enable it, login to the frontend, update the program and components, log back into FTP and disable the frontend. I have multiple sites I need to do this on and it takes a LOT of time. Plus, as I mentioned, the script is a security risk itself as WordPress users that load it and enable auto-updates are leaving a huge security hole on their systems. Being able to update within WordPress would be a matter of 2 seconds per site if implemented properly.

Would be nice to be able to click update from the WordPress installed Plugins section and have the script update without wiping out all custom components enabled.

Thanks!

[Maikuolan]

Hi,

No reason to feel bad, and I totally understand your frustrations. :-)

I run CIDRAM on a few different WordPress websites myself, and have encountered the same problems as well.

Finding a reliable solution to these problems has been on a the table for a while now (also see: #135, #180), and I definitely want to get this sorted out, but I haven't quite yet figured out the best way to proceed.

Ideally, what I'd really love to see is for WordPress to implement some new action hooks into their update system, so that I could make use of those hooks to have CIDRAM automatically restore all its own configuration, custom modules, etc by itself whenever WordPress tries to automatically update everything, but I've seen some other plugin maintainers already suggest this several times before at the WordPress support forums, and there doesn't seem to be much motivation at WordPress' side to implement something like that, so I doubt that'll happen at any time in the foreseeable future.

Other than that, I'd probably need to either (1) build some kind of bridge system, which could copy all of CIDRAM's old files to the WordPress database, allowing new versions of CIDRAM, when freshly installed/updated, to sync themselves back to the desired state via the copies of their own old files in the WordPress database.. which would probably work, but is kind of messy, and creates a lot of redundancy (plus, storing PHP files and such things within the database itself isn't really generally considered best practice among most developer communities, for security reasons, for the purpose of the correct utilising of technologies, etc). Or (2), actually build a completely new version of CIDRAM, specifically dedicated for just WordPress alone, rewriting CIDRAM in accordance with the WordPress standards, completely dropping the idea of flatfiles and other custom files for that version, and instead relying on the WordPress database for all that stuff.. which as far as the WordPress developer community would be concerned, would be the best approach to take, and would certainly be far less messy than the first approach, but would also, unfortunately, be a huge amount of work (relative to the first solution, plus my wishful thinking for action hooks which'll probably never eventuate), effectively forking CIDRAM again into two separate projects (or three, if we consider CIDRAM-L as a separate project).

Currently, as it stands, the "WordPress version" of CIDRAM is basically just the same thing as the normal version of CIDRAM, but with the addition of the basic data necessary for WordPress to recognise it as a plugin (a WordPress-specific README file, and a bootstrap file containing some metadata about the plugin within comments to link WordPress up with the the main CIDRAM loader file), which would be perfectly fine, and not any kind of problem in and of itself, if not for the particular problems at hand here (e.g., files being overwritten when updating due to that CIDRAM utilises flatfiles).

I'm sure that I'll eventually figure something out by myself regardless, one way or another, but in the meanwhile, I'm open for suggestions and advice, if anyone has any, regarding the best way to approach these problems, what would be ideal, any other possible ideas or angles that haven't been thought up or discussed yet and so on. Actually, I'd quite appreciate it. (Let's leave this issue open for a while. Maybe somebody will reply here with something).

[Maikuolan]

Another possible solution (3): Externalising custom files and configuration to a different directory, outside the vault, and outside CIDRAM's main directory. That way, when CIDRAM itself gets updated, customisations and configuration aren't overwritten/deleted, due to being externalised to a different directory. Less messy than solution 1, as well as less work and trouble than solution 2. But, the downside to this solution is that it would add an extra layer of complexity to CIDRAM: The fact that users wouldn't be able to simply click the "install" button to install it as a plugin anymore, since they'd need to also set up that external directory in order for their configuration, custom modules, signature files, etc to work properly (in which case.. it becomes questionable whether it's worth running it as a plugin at all, or whether it would be better to just install CIDRAM onto WordPress at a higher level, separate from plugins, as if it were any other kind of website).

Anyway.. I'll reply again if/when I can think of other ideas. If anyone else has any, or has thoughts about existing mentioned ideas, feel free to share.

[DanielRuf]

Another possible solution (3): Externalising custom files and configuration to a different directory, outside the vault, and outside CIDRAM's main directory

See how NinjaFirewall and NinjaScanner do it. They use wp-content/nfwlog and wp-content/ninjascanner.

[Maikuolan]

See how NinjaFirewall and NinjaScanner do it. They use wp-content/nfwlog and wp-content/ninjascanner.

Good idea. I'll take a closer look at that a little later this week. :-)

[737simpilot]

My advice until a solution is found is to just use the hook method via htaccess to hook CIDRAM rather than the plugin method. If you don't know how to do this just chime in and one of us can tell you how it's done. You may find it to be more robust and easier to use and maintain.

[Dibbyo456]

I use cidram with 20+ wordpress websites w/o any problems. The trick is don't use the wordpress plugin. Just hook the loader with .htacess or .user.ini in every wordpress setup.